[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Mnemomic names for revisions

From: Branko ─îibej <brane_at_xbc.nu>
Date: 2005-05-08 10:03:27 CEST

David Weintraub wrote:

>Okay, let's sum up here:

>The pro-label people are saying:
>1). We know we can create tags for labels, but this clutters up the
>archive tree since it literally creates a new directory. We don't want
>to contaminate the tree with hundreds and thousands of labels.
If labels were first-class objects, you'd need a way to manipulate them,
so you'd contaminate the namespace quite as much as with tags.

>2). Creating a tag creates a new revision. We simply want to label a
>revision (much like HEAD does) without creating a whole new archive
>version for it.
Heh. But labels as first-class objects would also have to be versioned,
otherwise you lose the time-invariant property of repositories (which
Subversion doesn't have, yet, because of the way revision properties are
implemented -- but I consider that a conceptual bug).

>3). We want to be able to create labels, do diffs, etc., without
>having to bother with URLs Doing "svn diff -rFOO:BAR myfile.cc" is a
>heck of a lot easier than:
>svn diff http://myserver/repos/tags/FOO/dir1/dir2/dir3/myfile.cc
It'll never happen exactly that way, because the repository-root part of
the URL can't be encoded inside the repository itself.

>4). Labels should be first class citizens. Creating a directory to
>represent a label is really a hack -- especially since you need a
>(so-far unpublished) hook to prevent someone from accidently changing
>what a tag points to in order to do this job correctly.
It's *not* unpublished. See svnperms.py in


-- Brane

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 8 10:04:56 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.