Sorry, I have to disagree with these arguments, Julian. I agree with
David that labels are a useful, and even necessary addition to SVN.
1. I don't really buy the "you can do it with tags, so who needs labels"
argument. Frankly, following this reductionist argument, you can do
everything SVN does with a well-designed directory layout/scheme, a DIFF
command, and a book detailing all the necessary conventions to follow.
So why does everyone use SCC systems? Because the *computer* should do
the book-keeping and grunt work, not the dev, since (a) it's what they
are good at and (b) it's what devs are bad at. However, the current tag
model is a convention enforced and manged by the dev/admin and not the
tool. Huh?
2. Following the "simple scenarios should have simple solutions" model,
how do I simply track a linear development process so that I can easily
refer back to an earlier rev for a quick diff? Without labels, I have
three choices (a) manually track dates/ rev numbers in some external
dataset (e.g. a spreadsheet), (b) over-load the message field with yet
another semi-formal data item or (c) use tags.
Now, (a) would seem to indicate a lack of something in the toolchain.
(b) is horrible since the message field is already badly overloaded (bug
tracking, branch merge tracking etc.). So we're left with (c), but this
is *not* a _simple_ solution to the simple problem -- far from it.
3. Tags, as second-class objects, are not understood by the toolchain.
What is the SVN command to compare two revisions of a file if I don't
remember the rev # of the earlier file? I have to wander around in the
tags directory, then manually construct a suitable svn command. Urgh!
IMHO there are already too many places where the svn "best practice" is
"scan the log messages for magic comments, note the rev #, type it into
a subsequent command" -- yet again, we are back into the devs doing
book-keeping for the computer!
4. Pragmatically, I have already seen too many shops using a "roll your
own" label scheme to believe that labels are unnecessary. Some shops use
external files and a nightmare of hacked scripts to inject revision
numbers into svn commands. Others hack them into properties and then
(again) hack together scripts to automate as much as possible. All of
these shops are working around what they see as a weakness in svn --
what they are *not* using, however, is tags.
So, why argue for labels? My feeling is that an SVN repo is in fact a
two dimensional store -- one dimension being the directory tree, the
other being the revision number. A node in this space is located by the
combination of (URL,REV#). Access to the URL co-ordinate is relatively
easy because (a) users remember mnemonic names quite well and (b) both
the OS and SVN provide many browse/search assists for this space. Access
to the REV# co-ordinate is *not* as easy since (a) users do NOT remember
numbers easily and (b) SVN provides few tools (and the OS none) to help
locate rev numbers.
Tags try to overcome this by essentially translating the REV#
co-ordinate _into_ an URL co-ordinate. Labels try to overcome this by
providing direct mnemonic aliases for the REV# co-ordinates. We already
have the tags solution, so why do we need labels? Because once a REV# is
translated to an URL via a tag, it *loses* information in the form of
its type -- the toolchain no longer understands that the tag is a REV#
and hence cannot usefully enforce or use that information. So there is
*no* direct way to specify the REV# _implied_ by a tag in an SVN command
-- hence all the awkward syntax and cumbersome use of URLs in many
otherwise simple SVN scenarios.
Put another way, an ordinary, plain old developer needs a simple way to
say "diff the current rev of foo.c against a known reference" that (a)
doesn't involve memorizing rev# and (b) doesn't require mastering branches.
--Tim
Julian Foad wrote:
> David Weintraub wrote:
> [...]
>
>> Is there another way to use "switch"? Can I simply "switch" just a few
>> files and not my whole working directory?
>
>
> Yes, and yes. You just specify the files and/or directories that you
> want to switch as arguments to the command.
>
>
> OK, so you don't want a "label" to just mark a point in time, you want
> it to mark a set of particular versions of particular files. So the
> concept is the same as Subversion's "tags"; it's just the useability
> that bothers you.
>
>
> If you will now agree that the concept that you call a "label" is the
> same as the concept that Subversion developers call a "tag", then we
> seem to have arrived at a shared view. (The need to set up hook
> scripts and use awkward syntax in order to use tags in Subversion is
> part of the implementation and user interface, not the concept.)
>
> Now we need to see in what respects the use is _too_ awkward at
> present, and in what respects it is just a little awkward but could be
> made better anyway, and then we could see about improving it.
>
> - Julian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 29 02:53:11 2005