I believe that Subversion currently provides a pretty good method for
creating labels or tags or mnemonic names or whatever you want to call it. I
have problems with the concept of "labels" used by many systems:
1). Many version control systems don't provide an easy way to find out what
labels are valid and what labels are not valid. RCS and CVS don't provide a
way to simply list all valid tags. In ClearCase, you need to use the "lstype
-kind:lbtype" command which is not exactly 100% obvious.
However, in Subversion, you can see all the various labels/tags/mnemonic
names by simply doing an "ls" of the tags directory.
2). Labels in most other systems aren't hierarchical. You have build labels,
qa labels, release labels, bug fix labels, and users like to create labels
too. The best you can do in most systems is to use a special prefix to
represent the "label type". In Subversion, you can classify labels as
directories. Put all of your build labels under one directory and release
labels under another. Allow users to create their own labels by simply
saving that label name under a directory named after that user.
In ClearCase, we might generate dozens of new labels each month -- sometimes
over 100 new labels in a single month. Sorting through the list to find the
information we want took a lot of time.This was especially true if we used
some sort of meta-data attached to the label to help better describe the
label. For example, we placed an attribute build_status on the label type to
let us know whether the build was good or bad. The implementation of
labels/tags as directories makes it much easier to classify the labels.
Yes, I do believe that labels are too easily modified and this is a major
problem. When I create a label, I should not be able to easily commit new
versions to it. Yes, this can be implemented with hooks, but it would be
really nice if there was some sort of locking mechanism that prevents
someone from making unauthorized or accidental changes to a label/tag. Maybe
the locking mechanism in Subversion 1.2 will do this.
Otherwise, Subversion's method of handling tags/labels is excellent.
-----Original Message-----
From: Tim Hill [mailto:tim@realmsys.com]
Sent: Friday, April 29, 2005 7:25 PM
To: Eric Hanchrow; users@subversion.tigris.org
Subject: Re: Mnemomic names for revisions
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.]
A "label" mechanism would elevate the tag concept to a first-class feature
in SVN, making the intensions of the label in-band, and obviate the need for
"tags" branches. Now, some aspects of such a feature are non-trivial: what
exactly do you label? A directory? Does each label create a revision? If a
label is a mnemonic for a revision, what does is mean to attempt to apply
that label to some other part of a repository outside of the labeled
directory?
Such issues would need to get resolved, but labels are indeed very useful
outside of tags, IMHO.
--Tim
Eric Hanchrow wrote:
"Tim" == Tim Hill <mailto:tim@realmsys.com> <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.
Received on Mon May 2 16:48:06 2005