Re: Subversion "labels" vs. "tags"

No one is saying there is no way to "label" a file as of now. It's
just unwieldy. When I was using SCCS, we created labels by creating a
text file containing a list of files and their version numbers we
wanted in a release and put those lists in SCCS. We were able to do
"labels" in SCCS, but no one complained when RCS came along and had
labels built right in.

Yes, you can use hooks to prevent tag corruption, but the concept of a
label should be internal to a version control system. Right now,
keeping the tags meaningful depends upon the administrator using hooks
or other means to keep users from destroying them. For example, with
the hooks I have in Subversion, no one can mess with the tags
directory, but no one can create a tag either.

Yes, you can use the diff --old=<URL> --new=<URL> label, but you have
to know exactly what you're looking for and the syntax is a bit
awkward to put it mildly:

$ svn diff --old=http://myweb/myrepos/myproj/tags/REL1.0/dir1/dir2/dir3/foo.c
--new=./foo.c

I guess you can even get around a few of the other commands with the
current implementation. For example, I'd like to use an older version
of a particular file in my current working directory. If I knew the
version number, I could do this:

$ svn update -r<REV> foo.c

But, I can't use the "svn update" with a tag at all. Instead, I have
to use svn copy:

$ rm foo.c
$ svn copy http://myweb/myrepos/myproj/tags/REL1.0/dir1/dir2/dir3/foo.c .

But is the behavior exactly the same? What would an "svn update" do,
or a "svn commit"?

As I said, it's possible to use the tag directory as currently
structured as a label, and I do use it, but it would be nice if there
was an easier way to use labels.

The reason we decided to start the discussion over here was to allow
the developers their say. How do they feel about adding a particular
set of features? What is the best way to implement such a feature? Is
it really worth the time and effort? Does it fit in with the way
Subversion currently works?

I understand not wanting Subversion getting feature bloat (Where are
the cup holders?). But labeling is a rather basic concept in version
control.

One of the options discussed on the user list was extending the
"directory for label" concept a bit more. Have a special "labels"
directory (like you have a "tags" directory), but give Subversion some
basic understanding of the concept of a label:

* Subversion itself would understand that the "label" directory is
special. Maybe specify the "label" directory (or maybe directories?)
in Subversion's repository directory.

* Subversion would understand that a "mklabel" command means doing a
URL copy to this specific directory.

* Subversion would let people "make labels" that is, do a URL copy to
an empty directory, but not allow just anyone to commit any changes
under this directory to pre existing files. Users can create labels,
but not modify them.

* Have Subversion understand that if a label is being specified in a
--revision parameter, you are really specifying the version of the
file that is under the "label" directory.

This way, the command set is being expanded by a single "mklabel"
command which is really just an alias to the copy command. There is no
real new data structure or concepts. There is no new name space
created. Just that Subversion now understands that a particular
directory has special meaning. You can list, edit, modify, and even
delete labels using the current Subversion command set (if you are the
administrator).

It sounds a bit difficult to implement, and there has to be several
items clarified. For example, if I have a repository directory
http://myrepos/myproj/trunk/dir/dir2/bin/, and I decide to make a tag
REL2.0 for bin, I could do any of the following:

$svn cp http://myrepos/myproj/trunk http:/myrepos/myproj/tags/REL2.0
$svn cp http://myrepos/myproj/trunk/dir http:/myrepos/myproj/tags/REL2.0
$svn cp http://myrepos/myproj/trunk/dir/dir2 http:/myrepos/myproj/tags/REL2.0
$svn cp http://myrepos/myproj/trunk/dir/dir2/bin
http:/myrepos/myproj/tags/REL2.0

All will save my bin directory under REL2.0. However, what does this mean?

$ svn co http://myrepos/myproj/trunk/dir/dir2/bin .
$ svn diff -rREL2.0 foo

Where does REL2.0 of foo exist in the archive? It all depends whether
I copied the whole structure to my REL2.0 directory, or just the bin
directory, or anything in between. How could Subversion know where I
put the file "foo" under the directory tags/REL2.0?

Another simpler method for implementing labels is to create a lookup
table containing labels and revision numbers (and maybe a reverse
lookup table). Now, when I specify:

$svn diff -rREL2.0 foo,

You can go to the lookup table, see what revision "FOO" represents,
and substitute that revision number.

Of course, that means adding a few more structures to the Subversion
archive, a command to make labels, a command to edit labels, a command
to list labels, a command to delete labels, etc. And, you now have
tags vs. labels as two different ways to do similar things. Plus, you
can't specify what exactly got labeled with a particular label. If my
repository contains multiple projects, all projects get that label.

We just thought it was time to get some developer input on the matter.

--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org