subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 'Daniel Shahaf' <...@daniel.shahaf.name>
Subject Re: svn move and <at> sign in filepath
Date Wed, 10 Jul 2013 01:45:02 GMT
Варфоломеев Игорь wrote on Wed, Jul 10, 2013 at 05:22:49 +0400:
> > From: Daniel Shahaf [mailto:d.s@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'?

Mime
View raw message