Re: SVN-4530 describes a really nasty bug in our command-line parsing

Branko Čibej wrote on Sat, 27 Oct 2018 23:19 +0200:
> $ touch wc/foo/@bar
> $ svn add wc/foo/@bar
> svn: E200009: 'wc/foo_at_bar': a peg revision is not allowed here
>
> Oh really? Since when are we allowed to ignore directory separators in
> paths?

wc/foo/@bar is parsed as path="wc/foo/", peg="bar", and the trailing
slash is stripped by canonicalization.

We _are_ overzealous about removing slashes: 'svn diff README/' works,
because of how early we canonicalize, but really shouldn't. However,
that's orthogonal to peg revisions.

> And why the blazes would 'svn add' ever look for the peg revision tag?

I assume it's for consistency, so scripts that call svn can do
.
    svn foo -- "${filename}@"
.
regardless of the values of foo and ${filename}.

> Digging into this now ... any pointers would be most welcome.

The example you gave results in an error message, so changing it raises
little compatibility concerns. However, when the peg revision is empty,
that's not the case. Consider:

% mkdir foo
% touch foo/@
% touch foo/bar@
% touch foo/bar
% svn add foo/@ # currently equivalent to 'svn add foo/'
% svn add foo/bar@ # currently equivalent to 'svn add foo/bar'

Making 'add' not parse peg revisions will change the meaning of
these commands.

Cheers,

Daniel
Received on 2018-10-28 01:57:52 CEST