Am 2018-09-09 um 13:50 schrieb Mark Phippard:

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@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@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?

The common parser was the first idea which came into my mind too.

Do you think it is worthwhile to file some issues about the incorrect help output?

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.

Thanks, I'll keep the code as-is for now.

Michael

Reply via email to