[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: Branko Čibej <brane_at_xbc.nu>
Date: 2005-11-04 00:58:05 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.
> In http://svn.haxx.se/dev/archive-2005-05/1367.shtml Greg Hudson wrote:
>> 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.
> Would there be a search procedure? For example, search upwards in
> parent and ancestor directories for the appropriate property until it's
> found? If the property is found but the transform rule is not found, do
> we keep searching, so that child directories can inherit transform rules
> from their parents?
> I think there needs to be some sort of wildcard and parameter
> substitution mechanism. The transform rules that take you to the trunk
> do not need a parameter, but the transform rules that take you to a
> branch or tag do need a parameter. The transform rules that take you
> away from a branch or tag similarly need to have a wildcard in the
> source path, which is not necessary in the transform rules that take you
> away from the trunk.
> # rule n args source path target path
> TRUNK 0 trunk trunk
> TRUNK 0 branches/* trunk
> TRUNK 0 tags/* trunk
> BRANCH 1 trunk branches/$1
> BRANCH 1 branches/* branches/$1
> BRANCH 1 tags/* branches/$1
> TAG 1 trunk tags/$1
> TAG 1 branches/* tags/$1
> TAG 1 tags/* tags/$1
> (The above table clearly needs a better syntax with less duplication.
> Notice that, at least in this example, the target path depends only on
> the rule, not the source path, and that all rules cater for the same set
> of source paths.)

I'm a bit dense these days... how would you define the mappings if you
have more than one branch directory in a repository?

Take for example the standard multi-project layour:


Or a more complex structure that I often use at work for a project with
global, unbranched stuff and stuff that is branched, with (at least) two
branching levels:

    docs/ (common, not branched)
    web/ (common, not branched)
    rel/ (release tags)
    stream1/ (one development stream -- release development)
       integ/ (integration branches)
       dev/ (development branches)
       tags/ (tags)

Note that in the case above, there's no special "trunk" -- all
development branches are equal. Stuff on development branches is
promoted to the local integration branch, tags for local integ and dev
branches are created in the local tags.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 4 00:58:10 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.