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@REV1 and URL2@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.
