Daniel Berlin wrote:
> This patch implements a prototype version of transform rules to save
> After playing with this for a while, I really like it. However, i very
> much would dislike the idea of trying to put these in dir properties,
> and would rather see just a new syntax for using these or something.
These rules have to be (at least) per-repository, and should ideally be
per-directory (really, per-project for multi-project repositories --
whatever). Putting them in the main config file is only a stopgap.
> To use it, apply the patch, then follow directions in config file setup
> and read up on command line syntax:
> Config file setup:
> add a section to ~/.subversion/config named "[transform-rules]".
There's way too much stuff in that file already...
> The syntax for each rule is "matchtext=replacement priority"
> Replacement may contain $[1-9], which will be replaced with an argument,
> if one is provided.
> Priority specifies the order of rule application.
> 1 We have to have a priority explicit (IE order in file doesn't change
> anything) unless we want to modify a bunch of config apis, or even the
> prop apis, because they throw it all in a hash.
I'd like to change the config implementation (not the APIs) so that the
enumeration functions maintain the order of the entries in the config
file. This would be useful for autoprops, and would make the priority
parameter here unnecessary.
We can easily put a config file in a property, and modify the config
file reader to use a svn stream instead of stdio for parsing the
> 2. The same applies for using the match text as the lhs.
> The other option is to require a bs name on the lhs.
> like: rule1=<match text> <replacement> <priority>
> or move priority there, so it's
> <priority>=<match text> <replacement>
> If you put the same name on the lhs, svn_config_* just store the last
> value into the hash, as expected (since they have the same key).
I suppose it wouldn't make sense to have the same match string for
different rules, yes? So, if I change the config parser implementation
as described above, that would fix most of the issues.
> Command line syntax:
> In order to make this easy to test, i've hooked it up to the url syntax.
> Url's starting with "rule://" will be tranformed according to the rules.
> To specify an argument to a rule, use # to separate arguments
> 1. Argument text cannot contain /, in this url syntax, since doing so
> would require adding an end argument delimiter.
> 2. The rule:// text is deleted as part of processing.
> 3. Where the occurrence of the text in the match part happens is of no
> consequence (IE we don't require it occur right after a / or anything).
> This would be easy to change
> 4. Each rule is applied exactly once per url, to the first match it
> finds. This would be easy to change.
> repo=svn://gcc.gnu.org/svn/gcc 3
> branches=repo/branches 2
> release=branches/gcc-$1-branch 1
> The command line:
> svn ls rule://repo
> will be turned into
> svn ls svn://gcc.gnu.org/svn/gcc
> The command line
> svn ls rule://release#4_0/gcc/ChangeLog
> will become:
> svn ls svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/ChangeLog
> (Note the recursive rule expansion, which happened in order of priority)
> I am not formally proposing we use the rule:// syntax, it's just a way
> to play with this.
> (Though i'm not opposed to it if people like it :P).
> Anyway, give this a try and tell me what you think.
> It seems to save me a lot of typing, with very little setup.
It strikes me that this doesn't actually solve the "diff --old --new"
issue; you'd still have to type the file name twice for a diff between
two branches. On the other hand, extending the -r syntax _would_ solve
svn diff --old rule://release#3_4/gcc/ChangeLog --new
svn diff -r release#3_4:release#4_0 gcc/ChangeLog
svn diff --old rule://branches/dfa-branch/gcc/tree.c --new
svn diff -r branches/dfa-branch:repo/trunk gcc/tree.c
(of course, you'd save even more typing if you renamed the -branch
suffix from all branch names in the GCC repository, now that tags and
branches are in different namespaces. :)
> I have no plans to implement Perl style matching and substitution, as
> we'd have to import a real library to do that (and POSIX regular
> expression syntax sucks rocks, IIRC:P)
OTOH we do have simple globbing in APR.
Anyway. I think this is an interesting proof-of-concept, but needs some
more vitamins and minerals to grow strong enough to be released into the
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Nov 6 09:11:39 2005