subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <s...@apache.org>
Subject Re: Don't reject arguments of the form ".@PEG"
Date Wed, 29 Oct 2014 13:07:46 GMT
On Wed, Oct 29, 2014 at 12:22:50PM +0000, Julian Foad wrote:
> An 'svn' command-line argument of the form ".@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/..@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 ".@PEG" were also being rejected.
> 
> I intend to correct this, to make arguments of the form ".@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.

Mime
View raw message