Варфоломеев Игорь wrote on Wed, Jul 10, 2013 at 05:22:49 +0400: > > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > > Sent: Tuesday, July 09, 2013 9:30 PM > > > > > Can you please file an issue for this? > > OK. I've just created the issue: > http://subversion.tigris.org/issues/show_bug.cgi?id=4392 > Thank you! > > > > (It's probably "bar@" that's the correct desination name in this case.) > > Em... is it? > I thought, " svn cares only about the last at sign in the argument, and it is > not considered > illegal to omit a literal peg revision specifier after that at sign. " > ( http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html ) > means that only "@" in "svn copy foo bar@" is considered as an "at-sign for > revision".
The rule for parsing a peg revision from a string is: if '@' is present, everything up to and not including the rightmost '@' is the path, and everything to the left of the rightmost '@' is the peg; else, the peg is unspecified. As it happens, an empty string after the rightmost @ is valid. That's why appending an '@' to a filename escapes it (regardless of whether the filename includes an '@' sign or not). The question is whether we should not be parsing peg revisions in some places. The target arguments to 'add' seem like a clear-cut case. The 'dest' argument of move seems like such a case too: assuming Q is a versioned directory, what would be the meaning of, say, 'svn move alpha beta gamma Q@r42'?
