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

Re: Mnemomic names for revisions

From: Johan Appelgren <johan.appelgren_at_gmail.com>
Date: 2005-04-30 11:45:29 CEST

> Eric Hanchrow wrote:
>> "Tim" == Tim Hill <tim@realmsys.com> writes:
>> Tim> I would certainly use revision labels if they were available,
>> Tim> why not?
>> I must be misunderstanding what revision labels are; to me they sound
>> like exactly the same thing as tags.
On 4/30/05, Tim Hill <tim@realmsys.com> wrote:
> Well, the goal is to provide a (typically) mnemonic identifier for a
> particular snapshot of an SCC system. Since in SVN all revisions *are*
> snapshots, this equates to a mnemonic for a revision. To date, the only way
> to do this in SVN has been with tags, which provide the mnemonic through the
> name of a folder path in the repository.
> I have two problems with this approach: (1) it clutters up the repository
> tree, which in big projects can be a mightmare, and (2) it's not clear
> except by convention that the "tag" should never be modified (otherwise its
> a branch, not a tag). I have trouble with #2 since it relies on out-of-band
> mechanisms (read: documentation+conventions) to indicate that it is a
> tag/label [sidebar: to my mind this is like saying we don't need "const" in
> a language since the same thing, more or less, can be done with comments.]

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 :)


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Apr 30 11:47:32 2005

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

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