On Mon, Mar 20, 2006 at 02:59:12PM -0700, John Calcote wrote:
> Understood. When I used the term immutable, I was referring to the
> contents of a work area arrived at via a tag, not the tag itself.
> Clearly, there are advantages to having tags be deletable, or movable.
I really _don't_ want to get involved in this conversation, but I would
like to throw in a quick point / use-case here that's not been mentioned
so far.
One (unexpected?) advantage of the fact that tags are _not_ immutable
in Subversion is that it's possible to use them in place of release
minibranches (that is, where a 'branding' or 'labelling' step needs to
be made before a release can be cut).
A good example is the Subversion codebase itself. When the
time came to release 1.1.0, we copied branches/1.1.x to
tags/1.1.0 (in r11188), then (in r11189) checked in a change to
tags/1.1.0/subversion/include/svn_version.h to label the tag with the
correct revision number [1].
The CVS alternative, where tags are immutable, is either to churn the
revision number on the branch as necessary (q.v. GCC), or to create
short-lived minibranches (branches/1.1.0-minibranch) onto which the
labelling change can be made (q.v. Mozilla) before the final tag
operation.
Regards,
Malcolm
[1] I note that we don't do this any more (instead, we tag from a working
copy that contains the right revision and the altered svn_version.h
file). But that's yet another 'non-CVS tag' operation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 21 10:45:55 2006