David Weintraub wrote:
> Over on the Subversion User List, there has been quite a discussion on
> the problems with "tags" and the need for a true object type called a
> "label". This discussion can be found at:
> <http://subversion.tigris.org/servlets/BrowseList?listName=users&by=thread&from=319767&to=319767&first=1&count=115>
> <http://tinyurl.com/d4ql8>
>
> After extensive debate, we felt it was time for the Subversion
> developers to get involved in our discussion.
Maybe it is, but you cannot make a worthwhile argument without acknowledging
the existing way of doing tags and saying what is deficient about it. In the
rest of your message, you do not do so.
I give some brief examples of the existing way below, just to show where you
need to make your arguments.
> We agree that tags have several short comings:
>
> Tags are not first class objects in Subversion -- just another
> directory. It is up to the administrator to know that a particular
> directory is a tag and not a branch. This type of knowledge is stored
> in the implementation of the site and not in Subversion itself.
Agreed. This may cause problems in some respects (but how, exactly?) while it
has advantages in other respects.
> Once a tag is created, there is no real mechanism built into
> Subversion that protects the sanctity of that tag. A user can checkout
> the tag's directory, make modifications, then commit those changes.
> This means an admin could create a REV1.0 tag directory, and have
> users change it without the administrator's knowledge.
Well, that behaviour is not built into the core program or active by default:
the administrator needs to set it up by installing an appropriate hook script.
Again, this can be seen as a shortcoming or as flexibility depending on one's
point of view.
> There is also no way a tag can be used in Subversion's "svn" sub
> commands.
Wrong.
> For example, in order to compare the current version of
> foo.c with foo.c in revision REV1.2, you have to either copy REV1.2's
> version of foo elsewhere and use an external diff command, or find out
> the revision number that was used to create REV1.2, then plug that
> into the diff command.
Wrong. You can do:
TAGS="http://blah.blah/repos/tags"
svn diff --old=$TAGS/1.2 --new=. foo.c
I'm not saying that's as simple as you want it to be, just that you have to
acknowledge it and analyse what is unacceptable about it if you think it is
unacceptable.
> It would be much easier if you could do this:
>
> $ svn diff -rREV1.2 foo.c
OK, so maybe we can work towards providing something more like that.
> On the Subversion User's list, we've discussed several ways to
> implement tags which I'm not going to go through here since that is
> really up to the developers. We do agree that we'd like to see the
> following features implemented:
>
> 1). There should be a fairly easy to use "svn mklabel" command that
> creates the label.
There is such a command, though it's called "copy" not "mklabel":
svn copy <whatever-you-want-to-label> $TAGS/1.2
e.g.
svn copy . $TAGS/1.2
or
svn copy http://blah.blah/repos/trunk $TAGS/1.2
>
> 2). Anyone should be able to create a label, but only the Subversion
> administrator should be able to change it. This would include editing
> the label, moving it, renaming it, and even deleting it.
Well, that may be the policy that you personally want today, but other
administrators might want to allow certain users to modify tags, at least for
some types of modification such as rename and delete. That's why the current
way of doing it is that the administrator sets the policy by choosing a
suitable pre-commit hook script.
>
> 3). You need to be able to list the various label names created.
Easy:
svn list $TAGS
>
> 4). Most importantly, all of the sub commands for svn and svnlook that
> take the --revision parameter must understand the concept of labels.
Well, all of them can access tags, as I demonstrated with "diff" above.
Whether they need to "understand the concept" is another question, and it is
for you to say why they should.
> That is, I should be able to specify a label rather than a revision
> number, and Subversion automatically does the right thing
Well, you can specify a tag instead of a revision number, although not in the
same syntax, and as I admitted above it may not be as simple as you would like.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 23 19:45:03 2005