[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sat, 27 Oct 2018 23:57:36 +0000

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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.