Tim Hill wrote:
>
> The problem, basically, is atomicity and simplicity. Why?
>
> Scenario: I fix a bug in "foo.c". I want to check it in, and annotate
> the check-in some way that is (a) meaningful and (b) can be used later
> in other svn commands to reference the file in question at the
> appropriate rev#.
>
There is a significant (conceptual) difference of "tagging" state (as
currently done in Subversion) and "tagging" revision numbers (as in
the proposed labeling scheme, if I understand correctly). With state
I obviously mean the contents of files and directories. Since version
control systems (like, for instance, CVS) frequently hide this
distinction, there is a lot of confusion about what tagging actually
does, can do, or is supposed to do. Also among the zealous, recently
converted Subversion enthusiasts, who promptly ignore this distinction
and proudly claim that "Subversion tagging can do everything".
:-/ or :-) ?
Since there is a distinction (referencing state vs a revision number),
I would say that the gain of introducing labels is there where you need
to refer to the revision by itself, as indicated earlier in the thread.
The question thus becomes which specific svn commands that need a
*revision number* (for the revision number, not the state behind it)
are you refering to in your scenario above? Diff-ing can be done using
tags (incl. merging, I think) since it uses state not the revision
numbers. So, are we only talking about showing specific ranges of log
messages? Or do I miss a significant other svn command?
The projected gain is obviously independent of the projected problems
of introducing a second namespace, questions of maintaining the history
of this second name space, and other as yet unknown problems. I have no
idea whether the project gains would ultimately outweigh the projected
problems. While I understand your frustration, if the situation was
really cut-and-dry, I suspect this feature would have been implemented
a long time ago...
But those are just my ¤0.02 ...
With regards,
Gerco Ballintijn.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 18 06:47:14 2006