Okay, let's sum up here:
The anti-label people are saying:
1). Tags already do exactly this. You can create as many tags as you
want, and delete the ones you no longer need. Creating a tag is
simple, quick, and takes up almost no disk space.
2). Creating another Subversion object type called a label means
having to implement all aspects of this feature. You've got to be able
to create, edit, and delete labels. Plus, you've got to be able to
find out what labels you have, and decide such things as what to do if
someone attempts to mark another revision with an already existing
label. That's a lot of work for a feature that already exists.
3). Tags, unlike labels, allow you to store your various labels
hierarchically, You can keep release labels in one directory, build
labels in another, and checkpoint labels in a third. Users can have
their own label directories to store their private tags. No name space
collision problems.
4). You can create a hook to prevent users from accidently making
changes in a "tag" that has been created.
The pro-label people are saying:
1). We know we can create tags for labels, but this clutters up the
archive tree since it literally creates a new directory. We don't want
to contaminate the tree with hundreds and thousands of labels.
2). Creating a tag creates a new revision. We simply want to label a
revision (much like HEAD does) without creating a whole new archive
version for it.
3). We want to be able to create labels, do diffs, etc., without
having to bother with URLs Doing "svn diff -rFOO:BAR myfile.cc" is a
heck of a lot easier than:
svn diff http://myserver/repos/tags/FOO/dir1/dir2/dir3/myfile.cc
http://myserver/repos/tags/BAR/dir1/dir2/dir3/myfile.cc
4). Labels should be first class citizens. Creating a directory to
represent a label is really a hack -- especially since you need a
(so-far unpublished) hook to prevent someone from accidently changing
what a tag points to in order to do this job correctly.
=====
I think that the arguments made by the pro-label side for arguments 3
& 4 are quite reasonable. Having to use a full URL just to do a diff
can be a problem. I also see the need for a better way to preserve a
tag once it is created, so it doesn't get accidently changed.
However, tags are extremely close to what the pro-label people are
clamoring for, and to create and fully implement another full object
type in Subversion just to go the last few yards will be using
development resources that could better be used in other areas.
Maybe what is needed is a way to specify that a particular directory
is the "tag" directory for that Subversion archive (and the default
could even be "<URL>/tags").
Once this is done, Subversion would do two things to this directory:
1). You can not easily commit another revision to any files in this
directory tree
2). Anytime you use a non-integer as a revision number in a Subversion
command, it will be assumes you are referring to a "tag" located in
this directory.
And, maybe one more:
3). Have an "svn label" command as an alias of the "svn copy". Well,
not quite an alias, but more of a shortcut:
$ svn label FOO
would be translated to
$ svn copy <current URL> <URL>/tags/<path>
or whatever is needed to actually create the tag directory.
Sounds good?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 8 06:21:33 2005