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:
project1/
trunk/
branches/
tags/
project2/
trunk/
branches/
tags/
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)
stream2/
integ/
dev/
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