> I've never used tags in CVS for anything else but marking just
> the current state, which really is nothing else then the
> current revision in SubVersion, so I failed to see that
> sometimes you'd like to mark some older versions of a file to
> be in a tag. But as svn cp can fix that problem it comes down
> to "no need for SubVersion to fix anything as there's nothing
> broken, you just have to change the way of thinking", am I
> right ?
I keep my point of view - svn copy is in fact branch creation,
not tag/label creation. One can workaround the lack of
tags/labels by creating branches every time the tag is needed
but it is not the natural way of working.
The mixed-revision tags are rare problem. The more frequent
problem with subversion 'tagging by copying' are just of the
ergonomic nature. It requires more effort to tag something in
subversion than in other version control systems (in cvs you
just write 'cvs tag mylib_1-0-4', in subversion you must write
'svn copy . http://my.repo.addr/tags/mylib_1-0-4' or sth
similar; similarly using GUI tools in CVS you just do sth like
Right-Click Tag and enter tag name, in subversion GUI will
require navigation to the tags directory). It requires more
effort to check the existing tags (same problem with navigating
to some location far away from the directory just being edited).
It requires more effort to checkout/update by the tag (same -
svn switch requires the path, on the other side, switch back
require the local dir path instead of sth like 'cvs up -A'). It
creates risk of creating unexpected branch just by the
accidental commit in the tag directory (I disagree with the idea
of using permissions or precommit to disable it, 'tag locking'
feature should be present by default not implementable, lack of
messages why pre-commit failed also adds to the problem). And it
creates risk of efficiency problems (operating huge tag
directory, accidental check out of that etc). Finally, all those
operations start being more error prone
(creating /taggs/mylib_1-0-0 instead of /tags/mylib_1-0-0,
checking out or web-spidering all the historical revisions
simultaneously, commiting to the tag, ...)
My view is of course strongly biased by corporate environment
where we place strong requirement to build often, be able to
reproduce both new and old builds and coordinate a lot of
version of a lot of modules for intersecting projects. Also the
fact that all the version-control tool I saw or read about
differentiate between labeling and branching could be both
considered as some additional argument for reconsidering the
current desing and observed as the way of thinking most
potential subversion users are prepared to...
By the way: it seems to me tags/labels could be *internally*
implemented using the svn copy, with some additional layer
above.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 5 18:13:25 2004