Greg Hudson wrote:
>[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.
>
>
But isn't that what an (URL,REV#) is?
>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.
>
>
Yes, this is certainly one way. The main objection I have to the current
scheme is that tags are just a convention, and as a result the toolchain
cannot use the implied REV# information directly -- it has to be
manually imputed by a user and translated by him/her to a REV# for
consumption by the toolchain. This makes scripting/automation difficult
for some common SVN operations and adds burden to the dev process.
>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 Tue May 31 21:56:27 2005