[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion "labels" vs. "tags"

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-05-24 02:15:26 CEST

Branko Čibej wrote:
> Julian Foad wrote:
>> Branko Čibej wrote:
>>> Once again, I'd like to draw attention to my proposal from a year ago:
>>> http://svn.haxx.se/dev/archive-2004-04/0973.shtml
>> That looks like it might be a sound basis on which to develop certain
>> sorts of features including symbolic naming of revision numbers. Can
>> you point to some use cases or a (fruitful) discussion of the need for
>> that feature?
> Ah. I recall there was a long thread on users@ and/or dev@ at the time,
> similar to the one we're having now.

Similar ... as in ... not fruitful? :-)

> As to use cases, I mentioned a few in the post; these are obvious:
> * Mnemonic labels are easier to remember than revision numbers

That's true, but it's a general reason why labels are useful in some cases, not
a "use case" which is a realistic example of using them in a particular way.

> * If you do magic with svnadmin dump/load, i.e., split or merge
> repositories, revision numbers will change, but revision labels
> will retain their meaning.

Right, good ... so a use case might be that when making a permanent reference
to a revision in a bug tracker, one would use the revision label "FIX_BUG_1234"
to refer to the revision(s) in which bug #1234 was fixed.

> * If you look at our backporting process, wouldn't it be nice if you
> could define a single mnemonic alias to all the revisions that
> need to be merged from trunk to a release branch?

Yup ... that's a good one. That's a "change set", pretty much.

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 24 02:16:07 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.