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

Re: Subversion "labels" vs. "tags"

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-05-30 17:57:16 CEST

[Tim forgot to cc his reply to the list; I've quoted his full message at
the end.]

On Sun, 2005-05-29 at 23:26 -0700, Tim Hill wrote:
> ok, what I'm really looking for is a more convenient way to express
> the REV# part of the (URL,REV#) co-ordinate space in a repo.

I think that's too specific. What you're really looking for is a more
convenient way to refer to previously identified versions of specific
files or directories.

Here are my incomplete thoughts on that issue:

  * It would be nice if we could make this easier for branches as well
as tags. Revision aliases might be a perfectly adequate solution for
tags, but we'd still have exactly the same set of complaints for
branches, as well as for tags made from branches.

  * If we restrict "previously identified versions" to mean branches and
tags as they are currently conceived of (and not just revision aliases
as being proposed), then the problem divides into two parts:

    1. Creating a transform scheme by which we can get from,
say, /trunk/subversion/libsvn_subr/foo.c (specified as just "foo.c" in a
working directory) to /branches/blah/subversion/libsvn_subr/foo.c,
without hardcoding layouts of the repository namespace. One option
would be to use directory properties to identify where the branches and
tags are.

    2. Creating a syntax to use this transformation scheme. One option
would be to invent a kind of revision specifier which transforms a URL;
another would be to invent a kind of URL syntax which uses the transform
rule; another would be to invent a new option type alongside -r.

I'll throw out a sketch of a straw-man proposal within the above
solution space: (1) we introduce a directory property "svn:transforms"
whose value is a series of lines which look like "T /trunk /tags". Each
line defines a named transformation rule; in the example, the rule name
is "T" and the rule substitutes the FS path prefix /trunk with /tags and
adds in the tag name as a path component; (2) we introduce a revision
specifier syntax "rule#path[@rev]" which transforms the URL according to
the svn:transforms value in the current directory, and uses either the
specified revision or the head revision. So you would do "svn diff -r
T#mytag foo.c" to diff a file against a tag, with the example transform
rule.

On Sun, 2005-05-29 at 23:26 -0700, Tim Hill wrote:
> ok, what I'm really looking for is a more convenient way to express
> the REV# part of the (URL,REV#) co-ordinate space in a repo. The
> trouble with tags is that the toolchain doesnt understand that a tag
> is really a REV# in disguise, as it were, and so its up to humans to
> track that and translate back to a real rev# when entering many SVN
> commands. This, to me, seems a significant deficiency in tags.
>
> So, is there some way this can be handled within the tag paradigm? It
> seems to me that a tag branch does imply a REV# (actually, a whole set
> of REV#s). What we really want is a way for the toolchain to accept
> these values as direct input to the --revision switch. That would
> imply that the --revision switch could accept an URL as an argument,
> though I've not thought through what this would actually mean
> semantically (yet).
>
> --Tim

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 30 17:58:16 2005

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