Actually, all this talk about tags "having no special meaning" brings
up another point that was bandied about this list a few years ago.
The concept was called "labels" (to help distinguish it from "tags").
Basically, a label would simply be an alias to a revision. For
$ svn mklabel REL-1.0 12345
This would make the label REL-1.0 synonymous with revision 12345. This
means you could now do things like this:
$ svn diff -rREL-1.0:HEAD
$ svn update -rREL-1.0
I know there are some limitations with this:
* You can't "edit" a label in order to change one program like you can
with a tag. Imagine if I create a release, and realize that I am
missing a few programs. With tags, I can edit the tag and add change a
few files. You can't easily do that with a label.
* A label would be across an entire repository. If I have multiple
projects, I can have a separate tag directory for each project.
Creating a label for project "A" would also create a meaningless label
for project "B".
* There has to be some changes in the back end because you'll now have
to create a label database. Not too bad since it wouldn't affect the
source in the repository.
* You now need a whole slew of commands to make, delete, and list your
repository tags. Older clients would not be able to do this, and
neither will order versions of your repository. We face this issue now
(Features in 1.5 that weren't in 1.4 and whether these are implemented
in the repository, client, or both), but while the other features were
sort of frosting-on-the-cake, this would be a major change, and if
heavily used, would really affect a whole range of developers.
But, at the same time labels would greatly simplify syntax, you could
easily do diffs, updates, and updates to a particular revision without
typing in complex URLs. There is no need to do research to find out
when a tag was created in order to do revision pinning, And, it would
also provide a built in mechanism to prevent accidentally changing the
meaning of a label/tag. No need for a special version of the svn "cp"
or "mv" command to prevent accidental double labeling.
$ svn co -rREL-1.0 svn://localhost/trunk/foo #Checking out a label
$ cd foo
$ vi program.cpp #Editing a program
$ svn commit #This will fail since you're not on HEAD!
$ svn co svn://localhost/tags/REL-1.0/foo
$ cd foo
$ vi program.cpp
$ svn commit #This will work, changing what you think is REL-1.0!
I know that Subversion works fine without "labels", and you can
provide shell scripts to emulate this stuff, but it would be nice to
have something like this built into Subversion. And, developers would
find Subversion a bit easier to use and comprehend.
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-29 18:10:27 CEST