On Sun, 2005-11-06 at 09:12 +0100, Branko Èibej wrote:
> Daniel Berlin wrote:
> > This patch implements a prototype version of transform rules to save
> > typing.
> >
> > 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.
>
No doubt.
However, we can't go stat'ing about and loading the entire world to
discover whether we have some transform rules or not. Also, storing it
in properties means readonly users are at a disadvantage, as are
read-write users who want their own rules.
I suppose we could come up with a sane file format that allows such
description, ask the server for it, and cache it for x days (specifiable
in the file).
Even that worries me.
> 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
> configuration.
Where would this property go?
The wc root?
I want to improve the prototype, so i need specifics :)
>
> > 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.
Right.
> >
> 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
> that. Consider:
>
> svn diff --old rule://release#3_4/gcc/ChangeLog --new
> rule://release#4_0/gcc/ChangeLog
>
> svn diff -r release#3_4:release#4_0 gcc/ChangeLog
>
> or:
>
> svn diff --old rule://branches/dfa-branch/gcc/tree.c --new
> rule://repo/trunk/gcc/tree.c
>
> 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. :)
Yeah, well :)
>
> > 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.
>
But it doesn't give you the amount of the pattern that has been captured
by the glob, so you have to effectively understand and apply the the
glob it in our case.
IE given the match text "foo*bar.", we could tell that this matched
"foofredbarforp", but we'd have to figure out on our own that it matched
only "foofredbarf", and do replacement on that portion.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 6 17:17:42 2005