Варфоломеев Игорь wrote on Wed, Jul 10, 2013 at 05:22:49 +0400:
> > From: Daniel Shahaf [mailto:d.s_at_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_at_r42'?
Received on 2013-07-10 03:45:38 CEST