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

Re: Inconsistencies/bugs in peg revision parsing and help description

From: Mark Phippard <markphip_at_gmail.com>
Date: Sun, 9 Sep 2018 07:50:53 -0400

>>> Any thoughts?
>> If I understand your examples, you are showing what happens when the filename contains an @, right? If so, this is addressed in the book in this paragraph:
>
> Correct.
>
>> "The perceptive reader is probably wondering at this point whether the peg revision syntax causes problems for working copy paths or URLs that actually have at signs in them. After all, how does svn know whether news_at_11 is the name of a directory in my tree or just a syntax for “revision 11 of news”? Thankfully, while svn will always assume the latter, there is a trivial workaround. You need only append an at sign to the end of the path, such as news_at_11@. 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. This workaround even applies to paths that end in an at sign—you would use filename@@ to talk about a file namedfilename@."
>
> Hi Mark,
>
> I am aware of that paragraph and this is what I did actually: https://github.com/apache/maven-scm/commit/c1f4f0fe1e0fafb876e098d8ecc17745664396ed
>
> It is still not clear why mkdir or export are subject to PEG parsing where it makes no sense at all, imho.

My guess is that there is just one parser used in the code base, but do not know. I do tend to agree that it seems to not make sense. It is something that may have been discussed before and maybe someone had a logic behind just being consistent everywhere?

> As far as I understand the paragraph, it is idiotproof to append the @ to all possible spots and have the issue fixed with thhat?

I believe so, yes.

Mark
Received on 2018-09-09 13:51:10 CEST

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

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