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

Re: Auto-subst of repository roots

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-11-03 15:46:26 CET

Alan Barrett wrote:
> On Thu, 03 Nov 2005, Greg Hudson wrote:
>>In http://svn.haxx.se/dev/archive-2005-05/1367.shtml I outlined a more
>>complicated proposal which saves significantly more typing. I'm not
>>sure it's a good idea, but I do think we should be aiming higher than
>>just repository root substitution.
> I agree that we should aim higher, and your proposed syntax looks
> promising.

Yes. Sorry that proposal didn't get much attention (from me at least) before.

>> I'll throw out a sketch of a straw-man proposal within the above
>> solution space: (1) we introduce [...]
>> 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 [...]
> Would there be a search procedure? For example, search upwards in
> parent and ancestor directories for the appropriate property

Let's not worry about where and how the transform rules are stored yet, but
concentrate on deciding whether the functionality that this provides is what we

> I think there needs to be some sort of wildcard and parameter
> substitution mechanism. [...]
> # rule n args source path target path
> TRUNK 0 tags/* trunk
> BRANCH 1 trunk branches/$1
> BRANCH 1 tags/* branches/$1


So, how would Daniel's GCC folks (for example) best use this scheme? How would
we Subversion developers best use it? What are the disadvantages compared with
any other suggestions?

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 3 15:47:17 2005

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

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