On Fri, May 20, 2011 at 11:14:45AM +0200, Ulrich Eckhardt wrote:
> Hi!
>
> I've seen quite a few people confused by peg revisions including myself, last
> case being the thread about "object oriented programming in MATLAB". Thinking
> about that, I'm more and more willing to consider the way peg revisions are
> taken from the commandline as a bug. The main reason is simply that it is
> surprising, which regular questions show.
It is documented in the book so I don't see how it can be surprising.
It can be awkward, unusual, or simply off-putting depending on personal
taste. But why surprising?
> I basically wanted to ask if there already is a bug ticket and if there even
> is consensus on how to treat it. I found ticket 2317, but I couldn't locate
> the according revision when this was fixed or how - the second part of the
> suggestion seems to not have been implemented.
The current consensus is the current syntax.
It can be escaped by appending an @ character at the end of the path
argument.
We've had bugs in some subcommands where the trailing @ was ignored:
http://subversion.tigris.org/issues/show_bug.cgi?id=3416
http://subversion.tigris.org/issues/show_bug.cgi?id=3651
Such bugs have caused confusion in the past since the behaviour
of several subcommands was inconsistent. But these should be fixed now.
If you find any additional bugs in peg revision handling, please let us
know :)
> Just for the record, my opinion is that the peg revision should not be part of
> the URL. At least it shouldn't be part of the URL's end, I'd rather add it to
> the beginning (specifying the root revision for the file tree) or maybe use
> the same way that POST parameters are encoded for HTTP ("/foo/bar?x=y&a=b").
That would not be as easy to type as the current syntax.
> However, I would prefer to have it as separate and explicit argument on the
> commandline, just as the "normal" revision is also passed with [-r|--revision]
What if you need to pass more than one peg revision argument?
E.g. for a merge I might need to pass URL1_at_REV1 and URL2_at_REV2.
What would the options be in this case?
Keep in mind that svn doesn't care where option names appear on the
command line. They can appear in any order and at any place.
> there. This makes it easier to understand and parse, and it avoids confusion
> because it is explicit and not mixed in the URL. I would then deprecate and
> warn about the peg revision in the URL for 2..3 years and then remove this
> syntax.
>
As per our compatibility guidelines we cannot remove this syntax at all
before Subversion 2.0. We can deprecate it but we need to keep supporting it.
Received on 2011-05-20 13:38:41 CEST