Re: Mnemomic names for revisions

Labels (aka "Mnemonic names") may actually be quite doable. However,
there has to be some limits and decisions made about how they work.

1). Labels should really be just a special class of tags. That way,
Subversion's archive format doesn't have to be changed for this
feature. Plus, users with clients that can't work with labels are
still able to find the files they're looking for.

Basically, a label would just be a default "tags" type directory (with
special attributes on it which will be explained later). When a user
specifies a "-r" flag with something besides an integer number, the
Subversion server will assume that the user is really requesting a
label and the server would fetch the version from the labels
directory. For example, if you entered the following command:

$ svn diff -r REL1.0 foo.c

Subversion would recognize that you really are comparing
<URL>/<labelDir>/REL1.0/<workingDir>/foo.c with the current version of
foo.c in your working directory and deliver the correct version to the
client.

2). There must be a way of specifying your default label directory,
but a special property won't work because it could be modified by
almost any user. Maybe a setting file under the repository's conf
directory. That way, you have to be on the server and have to have the
right permissions in order to change it. Much like changing hooks.

For simplicity, there should only be one label directory. Otherwise,
it will be much harder for the Subversion server to work out exactly
which directory contains the particular "label". I realize that this
is a problem for a single repository with multiple projects which
depend upon multiple tags directories. However, a good workaround
would be to allow subdirectories in labels. This way, each project
could still have its own label directory. For example:

$ svn diff -r proj1/FOO foo.c

would point to label FOO in proj1 while:

$ svn diff -r proj2/FOO bar.c

would point to label FOO in proj2.

The label directories won't be under the "project" directory, but at
least in Unix, this could be fixed with a few symbolic links.

3). For protection, a normal user maybe able to do a URL copy to a new
non-existent directory under the "labels" directory (i.e. create a new
label), but cannot do a commit. A normal user may checkout from a
"labels" directory, make changes in the code they checked out, but
will not be able to commit those changes.

I'm a bit concerned with this. I am not sure about the implementation
since I believe a URL copy pragmatically goes through the same commit
procedure a regular commit does. Also, if we allow a URL copy to a
subdirectory under the label directory (even if we make the
requirement that it must be a non-existent directory, it would still
be possible to cause problems.

For example, let's say I make a label by doing a URL copy to
<URL>/labels/proj1/REL1.0. I'm allowed to do this since the directory
<URL>/labels/proj1/REL1.0 doesn't already exist. However, what happens
if I "create" another label by doing a copy to
<URL>/labels/proj1/REL1.0/FOO? That is allowed since the directory FOO
didn't already exist under proj1/REL1.0. However, I now have a
subdirectory under my label REL1.0 which was not part of release 1.0.

Yes, you could allow the SCM to "fix" this, and you could have hooks
to prevent this, but the whole purpose of labels is to create a "first
class" implementation of the idea of labels.

4). For simplicity sakes, you should have a new command that creates a
label for you. In reality, it would just be a URL copy to the label
directory, but the syntax would be much simpler:

$ svn mklabel <label> <revision> [<directory>]

This would copy revision <revision> of the current directory (or the
directory specified) to the label directory <label>. This way, you
could label only a single project, just the trunk, or maybe only a
single directory of your code to the label directory.

If the label <label> already exists, the command will fail. If you
wanted to change a label, the Subversion administrator would have to
delete the label directory for you (as explained below).

5). The label directory tree would be treated as a normal directory if
the working directory is using the "file://" URL protocol. This will
ensure that the user is the Subversion administrator since you have to
be on the Subversion server *and* have the correct permissions to be
able to do a commit in order to use this protocol. This would also
allow the Subversion administrator to make "one-up" changes in the
label when needed, to delete and rename labels, or to move labels
around.

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