Yes, you can do some pre-commit "magic", but I think it's still somewhat
out-of-band. Don't get me wrong: the branch mechanism in SVN is
admirable, but overloading its use for labels is somewhat odd.
Would labels have to be a flat list? Why shouldn't I be able to label a
directory? At this point, a label looks an awful lot like a directory
property to me ("svn:label" ???). In fact, the only real change needed
in SVN itself would be to allow revision numbers to be specified using
labels, so, for example:
svn co URL -r !MYLABEL!
...would checkout the revision implied by the label (I made up the silly
syntax, substitiute as desired).
I can see several uses:
1. Eliminate need for "trivial" tags. Tags are good for major
milestones, where the visibility is a plus. But for every build?
2. Eliminate out-of-band data. If I equate SVN revisions to builds, then
tracking build numbers to revision numbers is of course trivial. But
many shops have build processes that are not so simple, and as a result
must track revision number to build number histories, creating YASLDF
(Yet Another Silly Little Data File). Far better to use labels and keep
everything within a single reference point -- SVN itself.
...and after all, we already have extensions to the "pure" revision
number model for dates, so why not labels?
--Tim
Johan Appelgren wrote:
>
><snip>
>
>Are aware that you can use a pre-commit hook to make the tags
>readonly? That would at least remove part of your problem with how you
>tag in subversion. And being able to put branches, tags and pretty
>much anything else in a clear hierarchy is in my eye less of a
>nightmare than having a huge flat list of labels. But then again, I'm
>probably missing something about how you envision labels to work :)
>
>/Johan
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
Received on Mon May 2 21:33:13 2005