> svn co URL -r !MYLABEL!
Now, you need a mechanism for listing the "labels" you created. And, someway
to prevent a user from creating a label with the same name (unless this is
an administrator only feature). You don't want a user to create a REL_1.0
label when you'd like to create one.
Don't think of the "tags" directory as a "directory". Instead, it is just a
place where you store valid labels. For example:
$ svnlook http://myserver/project <http://myserver/project> tags
#Lists all valid labels you created
svnlook http://myserver/project <http://myserver/project tags/builds>
tags/builds #Lists all valid build labels
Now, there is no need for a "list labels" command. Since labels could be
heirarical, you don't have a name space collision problem either. I could
create all the labels I want under the "tags/david" directory and not
interfere with anyone else or with the administrator. A little forthought
means you can quickly find all of the various labels you're interested in.
Your above command is equivellent to something like this:
svn co http://myserver/projects/tags/MYLABEL
<http://myserver/projects/tags/MYLABEL>
This will checkout all of the sources that are under MYLABEL into the
current working directory.
The only problem is that (without any hooks), I could change, add, and
delete files in this working directory and then check them back in under
http://myserver/projects/tags/MYLABEL
<http://myserver/projects/tags/MYLABEL> without really thinking about it.
The only thing I'd like to see is some sort of locking mechanism that
prevents commits unless I do an unlock first. There are times I might want
to make a quick "one up" correction in a file without going through a whole
build process.
-----Original Message-----
From: Tim Hill [mailto:tim@realmsys.com]
Sent: Monday, May 02, 2005 3:25 PM
To: Johan Appelgren
Cc: Subversion Mailing List
Subject: Re: Mnemomic names for revisions
Yes, you can do some pre-commit "magic", but I think it's still somewhat
out-of-band. Don't get me wrong: the branch mechanism in SVN is admirable,
but overloading its use for labels is somewhat odd.
Would labels have to be a flat list? Why shouldn't I be able to label a
directory? At this point, a label looks an awful lot like a directory
property to me ("svn:label" ???). In fact, the only real change needed in
SVN itself would be to allow revision numbers to be specified using labels,
so, for example:
svn co URL -r !MYLABEL!
...would checkout the revision implied by the label (I made up the silly
syntax, substitiute as desired).
I can see several uses:
1. Eliminate need for "trivial" tags. Tags are good for major milestones,
where the visibility is a plus. But for every build?
2. Eliminate out-of-band data. If I equate SVN revisions to builds, then
tracking build numbers to revision numbers is of course trivial. But many
shops have build processes that are not so simple, and as a result must
track revision number to build number histories, creating YASLDF (Yet
Another Silly Little Data File). Far better to use labels and keep
everything within a single reference point -- SVN itself.
...and after all, we already have extensions to the "pure" revision number
model for dates, so why not labels?
--Tim
Johan Appelgren wrote:
<snip>
Are aware that you can use a pre-commit hook to make the tags
readonly? That would at least remove part of your problem with how you
tag in subversion. And being able to put branches, tags and pretty
much anything else in a clear hierarchy is in my eye less of a
nightmare than having a huge flat list of labels. But then again, I'm
probably missing something about how you envision labels to work :)
/Johan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
<mailto:users-unsubscribe@subversion.tigris.org>
For additional commands, e-mail: users-help@subversion.tigris.org
<mailto:users-help@subversion.tigris.org>
Received on Mon May 2 23:04:19 2005