You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Berlin <db...@dberlin.org> on 2005/11/06 03:35:10 UTC
[PATCH]: Transform rules prototype
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.
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]".
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.
Note:
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.
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).
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
NOTES:
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.
Examples:
Given:
[transform-rules]
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.
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)
--Dan
Re: [PATCH]: Transform rules prototype
Posted by Daniel Berlin <db...@dberlin.org>.
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
Re: [PATCH]: Transform rules prototype
Posted by Daniel Berlin <db...@dberlin.org>.
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.
> 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
Like i said, i have no problem with extending -r.
I just put out a prototype to play with.
If someone wants to give a real syntax to use, i'm happy to implement
it.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Transform rules prototype
Posted by Branko Čibej <br...@xbc.nu>.
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.
> 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.
>
> Note:
> 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
configuration.
> 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
> NOTES:
> 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.
>
> Examples:
> Given:
>
> [transform-rules]
> 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
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. :)
> 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
wild.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Transform rules prototype
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-11-06 14:34:46 -0500, Daniel Berlin wrote:
> On Sun, 2005-11-06 at 20:15 +0100, Vincent Lefevre wrote:
> > release#*/=branches/gcc-$1-branch/
>
> Really ugly, IMHO.
Perhaps the way to write rules should be configurable. :)
> > The special characters are the following ones:
> > 1. At the beginning of the rule, ^ means that the match must occur
> > at the beginning of the string.
> > 2. * matches anything up to the separator (following *), if there is
> > one. For instance, in the 3rd rule above, * would be equivalent
> > to [^/]* in a regexp.
> > 3. In the replacement text, $[1-9] is replaced by the corresponding
> > matched text. $. is replaced by the URL given by svn info.
> >
> 2 is non-easy without a regex library, we need to discover what it
> captures.
2 would just be a simple loop until some given character is
encountered (or the end of the string). No need for any library
for that.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Transform rules prototype
Posted by Daniel Berlin <db...@dberlin.org>.
On Mon, 2005-11-07 at 17:19 +0000, Julian Foad wrote:
> Branko Čibej wrote:
> > Daniel Berlin wrote:
> >
> >> Again, i believe it's way too early for a design doc. You need to have
> >> some idea of what kind of ui you actually want before you can work up a
> >> design doc.
> >>
> >> How the heck are you supposed to decide what UI's work if you can't try
> >> them in a real world situation?
> >
> > O.K., I misunderstood.
> >
> > Then may I suggest we do this on a branch?
>
> It's easy enough for me to try out an idea like this by applying a patch mailed
> to the list. I think a branch in our repository is only needed if the
> development is going to get complex and more than one person is going to be
> working on it. I think Daniel means "Let me code some of these ideas: it's the
> quickest way to try them out," and not that the code should be committed to the
> repository before we're happy with the design. That's quite reasonable: it
> saves us trying to imagine what it would be like to use the feature. Daniel, I
> hope I understood you better here than I did in that other thread.
>
Yes, you are exactly right in what my intention was.
Of course, if people don't think it's useful enough, i'm happy to just
try this on my own, and see what i think works :)
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Transform rules prototype
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> Daniel Berlin wrote:
>
>> Again, i believe it's way too early for a design doc. You need to have
>> some idea of what kind of ui you actually want before you can work up a
>> design doc.
>>
>> How the heck are you supposed to decide what UI's work if you can't try
>> them in a real world situation?
>
> O.K., I misunderstood.
>
> Then may I suggest we do this on a branch?
It's easy enough for me to try out an idea like this by applying a patch mailed
to the list. I think a branch in our repository is only needed if the
development is going to get complex and more than one person is going to be
working on it. I think Daniel means "Let me code some of these ideas: it's the
quickest way to try them out," and not that the code should be committed to the
repository before we're happy with the design. That's quite reasonable: it
saves us trying to imagine what it would be like to use the feature. Daniel, I
hope I understood you better here than I did in that other thread.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Transform rules prototype
Posted by Branko Čibej <br...@xbc.nu>.
Daniel Berlin wrote:
> Again, i believe it's way too early for a design doc. You need to have
> some idea of what kind of ui you actually want before you can work up a
> design doc.
>
> How the heck are you supposed to decide what UI's work if you can't try
> them in a real world situation?
>
O.K., I misunderstood.
Then may I suggest we do this on a branch?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Transform rules prototype
Posted by Daniel Berlin <db...@dberlin.org>.
On Sun, 2005-11-06 at 21:49 +0100, Branko Čibej wrote:
> Daniel Berlin wrote:
> > Anyway, i'm just going to implement prepending transform rules for now,
> > and a -t syntax, and remove the current rule://
> >
> Pleas don't hurry so. I know the GCC people want this, but we can't
> release a change like this before 1.4, and there's not been even
> remotely enough discussion on the list.
Again, i'm just playing around with various options.
I have *serious* doubts we are going to be design a good UI by simply
talking about it here.
In fact, i'd -1 any discussions of this feature that have no real
implementations behind them to try.
I believe that's one of the ways we got into this problem of
ridiculously long command lines in the first plcae.
>
> Please let's do things the right way. Start with a design doc stating
> the goal of the change, defining the syntax formally, exploring effects
> on current commands, etc. etc. etc. Then we'll discuss this design on
> the list. *Then* we'll implement it.
Again, i believe it's way too early for a design doc. You need to have
some idea of what kind of ui you actually want before you can work up a
design doc.
How the heck are you supposed to decide what UI's work if you can't try
them in a real world situation?
>
> Even though I support this idea in general, it's so sweeping a change
> that it gets a -1 from me if it's implemented without all the necessary
> process that such a change requires.
That's fine.
>
> -- Brane
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Transform rules prototype
Posted by Branko Čibej <br...@xbc.nu>.
Daniel Berlin wrote:
> Anyway, i'm just going to implement prepending transform rules for now,
> and a -t syntax, and remove the current rule://
>
Pleas don't hurry so. I know the GCC people want this, but we can't
release a change like this before 1.4, and there's not been even
remotely enough discussion on the list.
Please let's do things the right way. Start with a design doc stating
the goal of the change, defining the syntax formally, exploring effects
on current commands, etc. etc. etc. Then we'll discuss this design on
the list. *Then* we'll implement it.
Even though I support this idea in general, it's so sweeping a change
that it gets a -1 from me if it's implemented without all the necessary
process that such a change requires.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Transform rules prototype
Posted by Daniel Berlin <db...@dberlin.org>.
On Sun, 2005-11-06 at 20:15 +0100, Vincent Lefevre wrote:
> On 2005-11-05 22:35:10 -0500, Daniel Berlin wrote:
> > Url's starting with "rule://" will be tranformed according to the rules.
>
> Since this is configurable, why not transforming *any* URL-like string?
Okay, it's clear to me now that when i say "I've hooked this up to
rule:// as a prototype to play with easily", people think i mean more
than "I've hooked this up to rule:// as a prototype to play with easily"
> The end argument delimiter could be given in the rule, e.g.
>
> release#*/=branches/gcc-$1-branch/
Really ugly, IMHO.
>
> The * is a special character that matches anything up to the
> 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
>
> There would be a problem with your example and something like that:
It will be a problem with a lot of things.
ItI'd rather see this written like this (following my comments above):
>
> ^rule://repo=svn://gcc.gnu.org/svn/gcc 3
> ^rule://branches=rule://repo/branches 2
> ^rule://release#*/=rule://branches/gcc-$1-branch/
>
> The special characters are the following ones:
> 1. At the beginning of the rule, ^ means that the match must occur
> at the beginning of the string.
> 2. * matches anything up to the separator (following *), if there is
> one. For instance, in the 3rd rule above, * would be equivalent
> to [^/]* in a regexp.
> 3. In the replacement text, $[1-9] is replaced by the corresponding
> matched text. $. is replaced by the URL given by svn info.
>
2 is non-easy without a regex library, we need to discover what it
captures.
I'm trying to avoid this.
Anyway, i'm just going to implement prepending transform rules for now,
and a -t syntax, and remove the current rule://
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Transform rules prototype
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-11-05 22:35:10 -0500, Daniel Berlin wrote:
> Url's starting with "rule://" will be tranformed according to the rules.
Since this is configurable, why not transforming *any* URL-like string?
If a user wants to transform only strings starting with "rule://",
he should be allowed to specify that in the rules.
> 1. Argument text cannot contain /, in this url syntax, since doing so
> would require adding an end argument delimiter.
The end argument delimiter could be given in the rule, e.g.
release#*/=branches/gcc-$1-branch/
The * is a special character that matches anything up to the
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
There would be a problem with your example and something like that:
svn ls rule://repo/dir/branches.c
> 4. Each rule is applied exactly once per url, to the first match it
> finds. This would be easy to change.
>
> Examples:
> Given:
>
> [transform-rules]
> repo=svn://gcc.gnu.org/svn/gcc 3
> branches=repo/branches 2
> release=branches/gcc-$1-branch 1
I'd rather see this written like this (following my comments above):
^rule://repo=svn://gcc.gnu.org/svn/gcc 3
^rule://branches=rule://repo/branches 2
^rule://release#*/=rule://branches/gcc-$1-branch/
The special characters are the following ones:
1. At the beginning of the rule, ^ means that the match must occur
at the beginning of the string.
2. * matches anything up to the separator (following *), if there is
one. For instance, in the 3rd rule above, * would be equivalent
to [^/]* in a regexp.
3. In the replacement text, $[1-9] is replaced by the corresponding
matched text. $. is replaced by the URL given by svn info.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Transform rules prototype
Posted by Daniel Berlin <db...@dberlin.org>.
On Sun, 2005-11-06 at 10:50 +0200, Alan Barrett wrote:
> On Sat, 05 Nov 2005, Daniel Berlin wrote:
> > This patch implements a prototype version of transform rules to save
> > typing.
>
> > 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
>
> This still doesn't handle deeply nested directories conveniently.
>
> For example, if you are working in a deeply nested subdirectory of the
> working copy, and you want to diff a file against the corresponding file
> in the corresponding deeply nested subdirectory of another branch, you
> still need to say something like this:
>
> svn diff rule://release#4_0/gcc/fixinc/tests/base/arch/i960/archI960.h \
> archI960.h
>
> where Greg's proposal would allow something like this:
>
> svn diff -r release#4_0 archI960.h
Yes, but his proposal has it's own set of issues, such as requiring
dir-props (which means read-only users can't set them), and the
disadvantage that now every single command will have to play around in
the wc to try to find transform rules, which IMHO, is a very bad idea.
I'm not opposed to a -t or -r style syntax that appends the current path
in the repo to the end of the command.
But we also can't make this scheme so complex that nobody actually
understands how to work with it.
>
>
> Also, if you invent your own URI scheme,
I'm sorry you wrote the rest of that detailed explanation. I thought i
made it clear that I only made it rule:// to make it easy to play with.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Transform rules prototype
Posted by Alan Barrett <ap...@cequrux.com>.
On Sat, 05 Nov 2005, Daniel Berlin wrote:
> This patch implements a prototype version of transform rules to save
> typing.
> 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
This still doesn't handle deeply nested directories conveniently.
For example, if you are working in a deeply nested subdirectory of the
working copy, and you want to diff a file against the corresponding file
in the corresponding deeply nested subdirectory of another branch, you
still need to say something like this:
svn diff rule://release#4_0/gcc/fixinc/tests/base/arch/i960/archI960.h \
archI960.h
where Greg's proposal would allow something like this:
svn diff -r release#4_0 archI960.h
Also, if you invent your own URI scheme, please note that schemes that
use the "://" syntax are special. (See RFC 3986, and search for "//"
and "authority".) Essentially, if the scheme uses the "://" syntax,
then the part between the "://" and the third "/" is required to be a
host name or user@host or similar, and the part after the third "/" is
required to follow the rules for relative URIs (e.g. ".." must work in
the usual way). You are using "://" in a way that is not allowed by the
generic syntax for URI schemes, because you don't have anything like a
host name; perhaps you could use "rule:" instead of "rule://" to avoid
this problem.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org