Daniel Patterson wrote:
> Although I suggested some kind of ability to search revprops, I'll
> just make it known that I think it's simply better to do:
> svn co $URL/tags/Build_123
> (and it's nice and short like you want ;-) ). If you don't want
> labels that could change, use a pre-commit hook to lock them
> down. As I mentioned earlier, I think it's a really bad idea
> to make the namespace multidimensional (i.e. you're suggesting
> you need *two* bits of information, the label and the URL).
> By putting the label name as part of the URL, you automatically
> avoid namespace conflicts and ambiguity. (In your scheme, is
> a URL much use without a label, or vice versa?)
But the namespace already *is* multidimensional -- that's what a
revision is! A label doesn't add another dimension, it just makes
working with the revision "dimension" easier. What's wrong with that?
> And this can all be achieved right now without any special extra label
> type. Subversion is already recording all the information you need
> to fully reconstruct history. After you've made a tag, you can do:
> svn log --verbose --stop-on-copy $URL
> This'll tell you:
> a) At what revision the tag was made
> b) Where it was copied from (if that was some other arbitary
> revision, or indeed if it was a mixed-revision tag).
> From those bits of information, you can easily work out what
> branches were around at the time, etc.
..and this very example illustrates one of my arguments for labels --
the (bad) need to manually transfer revision information from the output
of filtered log commands to the input of other SVN commands. Your
arguments are basically that I can *technically* do whatever is needed
w/o labels. While this might be correct, I think it misses the point.
What labels buy is convenience and ease-of-use -- svn does more manual
drudge work and book-keeping, freeing devs to work on more constructive
Let's face it, I could do *everything* svn does with a clever use of
directory name conventions and/or a few hack scripts and a DIFF command.
So why do people use SVN or its equivalents? Because it
enforces/guarantees/standardizes what would otherwise be a loose
convention subject to abuse into a formal, robust system.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon May 16 21:03:38 2005