David Weintraub wrote:
... stripped ...
Thanks for nice summary of pro- & anti-label arguments.
What about make labels as property "svn:label" on revision object?
Revisions are non-versioned as their properties, but for this
purpose would be fine. Of course, using labels will be slower but
comfortable. I guess I'm not the first, who suggest this but it's
pretty straightforward and it meets requirements.
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 8 12:04:09 2005