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

Re: Don't reject arguments of the form ".@PEG"

From: Stefan Sperling <stsp_at_apache.org>
Date: Wed, 29 Oct 2014 14:07:46 +0100

On Wed, Oct 29, 2014 at 12:22:50PM +0000, Julian Foad wrote:
> An 'svn' command-line argument of the form "._at_PEG" raises the error
>   svn: E125001: '@PEG' is just a peg revision. Maybe try '@PEG@' instead?
> That error is annoying to me, and unnecessary.
> This happens for pretty much any 'svn' command, with any path that is converted to "" on canonicalization and conversion to "internal style". It is inconsistent with how we interpret other arguments containing a peg specifier, including arguments such as "foo/.._at_PEG" which also refer to "this directory" at a semantic level but which are not collapsed to "@PEG" at a syntactic level.
> I think the reason that error was introduced (by stsp in r878062) was to prevent people being caught out when we changed the interpretation of a filename that starts with "@" such as "@file". Before r878062 that had been interpreted as a filename, and afterwards as a peg revision.
> It seems to me that check should only reject command-line arguments of the form "@PEG", and not of the form ".@PEG". However, the check was in a low-level function () that is used both after conversion to internal style as well as before conversion, so arguments of the form "._at_PEG" were also being rejected.
> I intend to correct this, to make arguments of the form "._at_PEG" syntactically acceptable.
> - Julian

I agree this should be fixed.

I once tried but couldn't figure out a good fix because of the
chicken-and-egg problem of canonicalization vs. peg-revision parsing.

The current implementation canonicalizes first and then looks for peg
revisions. Perhaps we should change the order of these operations,
however these operations currrently happen in different layers of
code. And we might end up interpreting non-canonicalized input, which
may or may not pose a problem, dunno...

Or we could mark empty paths in some special way during canonicalization
so the peg revision parser has a chance to interpret a '.' path.
Perhaps we could even internally replace '.' with the absolute path of
the current working directory during canonicalization.
Received on 2014-10-29 14:09:02 CET

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.