On 5/16/05, Dirk Schenkewitz <schenkewitz@docomolab-euro.com> wrote:
> > Let me clarify: Once the label is released outside of the development
> > organization, it should never be changed.
> > ...
>
> Ok, I agree - as long as there is nothing "handed out", it would be
> good to be able to change a label. Also in the case of a typo. But
> these should be very rare cases. To rename a label should IMHO be an
> admin command.
Absolutely!
Users should be allowed to use labels, but if them make a mistake,
they'd have to ask the admin to fix it. The hope is that the Admin
knows what they're doing. Admins should have the ability to fix (or
create) almost any problem.
> > Don't think of labels as just ways of marking releases, but as ways of
> > creating a snapshot of your archive in time.
>
> Isn't that exactly what tags do? That's not what I want - I rather want
> to give a (symbolic/mnemonic) name to a certain svn revnum, nothing else.
>
> As you describe it, "label" seems to be just another name for "tag".
> I don't see a difference. (Except that a tag cannot be used instead of
> a svn revnum, but i'm not sure if you're interested in that.)
In truth, everything you want with the symbolic/mnemonic name could be
done with tags. However, tags have two problems: They aren't "first
class" objects, but just a special way of handling branches. To really
implement tags, you have to write a hook script to keep them from
being "changed" by a user treating them like a branch. Plus, as you
argued, you cannot use easily use them in many Subversion commands.
You want to be able to say:
$ svn -r REL1.1:REL1.2 foo.c
And, there is no way with the current "svn diff" command that you can
do this easily with tags.
You'd like to see it done via a look up table: REL1.1 = revision 12335
and REL1.2 = revision 12544.
I am proposing that this could be done with a special implementation
of tags. A label is a tag with some special properties:
1). Unlike a "normal" tag, if you checkout files from under the
special "label" directory, you are not allowed to commit them to the
archive (unless you're the administrator). This would eliminate the
need for hook scripts to do this for you.
2). When a user specifies a non-integer revision, Subversion would
understand this is a label and not a revision number. Subversion would
fetch the version of the file under the "label" directory for the
command. This would include all the svn commands that take the
--revision flag.
In both of our methods, we could do this:
$ svn diff -r REL1.1:REL1.2 foo.c
It's just a difference of implementation.
In your method, the implementation is fairly straight forward.
However, you need to change the archive structure to use a new table
to track labels. Plus, you need a way to list labels, delete labels
(Yes, you want to be able to destroy obsolete labels), and other
commands to handle label implementation.
You're also limited with the usefulness of labels. If you've got
multiple projects in your archive, you cannot label them
independently. Plus, if you want to label a release to customers,
you're not just labeling what went into that release, but the entire
contents of your archive whether or not those files were part of the
release (or even shouldn't be considered part of the release).
My method would be trickier to implement, but it's more flexible. You
can label just the products in your release, or if you prefer, the
whole trunk. You also don't need a series of commands to delete,
modify, or list labels. Plus the current archive structure doesn't
have to be changed to implement this feature. (You can't keep asking
people to dump and load their entire source archives every time a new
feature is added to Subversion). You can even browse through your
releases via http if you're using Apache.
You're right that every other version control system simply uses
labels as a mnemonic name for a particular version of the file, but
Subversion doesn't version files, but the whole archive. Where as
under CVS and RCS, I could pick and choose which files and which
versions to label, under Subversion, I am labeling all or nothing
across the entire archive.
Versioning the entire archive is what makes Subversion so powerful,
but it is also its major weakness. That's why you can't do such things
in Subversion as completely obsolete versions of a file or the delete
one file from the archive. It's probably why tags were originally
implemented the way they were.
No matter what, the concept of labels as a "first class" object in
Subversion is sorely needed. And, it should be implemented in such a
way to guarantee that labels are automatically protected once they're
laid down. In most other version control systems, only the
administrator is allowed to create labels, or if a user is allowed to
create labels, no one (except for the administrator) is allowed to
modify them. The same must be true in Subversion.
Labels should be usable in most Subversion commands too, so that it is
easy for a user to refer to a specific version of a file by an easy to
remember label and not some random integer.
So far, we've discussed three various ways labels could be
implemented: As a special property, as a look up table, and as a
special form of tag. Each of these ways have advantages and
disadvantages in their implementation in terms of ease of
implementation, flexibility, and speed. However, they're implemented,
labels certainly will be a welcome addition in Subversion.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 16 23:53:46 2005