Garrett Rooney wrote:
> On 5/17/06, Julian Foad <firstname.lastname@example.org> wrote:
>> Note also that "@PREV" is not a valid peg specifier: [...]
> I'm not convinced @PREV or @COMMITTED are invalid. It's just a matter
> of converting them to a url/rev pair and then doing exactly what we
> would do with any other peg revision argument...
Forget about COMMITTED for a moment, and think about how PREV could be
interpreted as a peg revision and converted to a URL/rev pair.
$ svn something -r10 http://repos/foo@20
In the tree "r20", find path "foo", then trace it back to r10 (in which it was
$ svn something -r10 foo (@WC implied)
In the tree "WC", find path "foo", then trace it back to r10 (in which it was
$ svn something -r10 foo@PREV
In the tree "PREV" (uh, what revision tree would that be?) find the path "foo"
- (uh, the tree only exists in the repository, so we ought to be looking for a
Maybe try a different interpretation...
In the tree "WC", find path "foo", then trace it back to rPREV = r15 (in which
is was called .../middle_path/baz), then trace it back to r10 (in which it was
called /old_path/bar). But that double trace-back is necessarily equivalent to
the single one specified by "-r10 foo" (@WC implied).
That's why I say "@PREV" is an invalid peg specifier.
"@COMMITTED" is similar, but because "COMMITTED" refers to the same version of
the object as does "BASE", it's sometimes a little harder to convince oneself.
> Regardless, I do agree that this stuff could be consolidated, but I
> think it can wait. The patch I committed is what is minimally needed
> to fix this problem, and can easily be merged into 1.4.x without much
> danger. A more wide reaching change to consolidate the handling of
> this stuff is probably warented, but seems like a it risks changing
> behavior unexpectedly somewhat late in the game for 1.4.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri May 19 23:30:57 2006