Am 2018-09-09 um 13:33 schrieb Mark Phippard:
On Sep 9, 2018, at 6:46 AM, Michael Osipov <micha...@apache.org> wrote:
Folks,
while working on SCM-859 I have found some oddities on Subversion 1.9.7 and
1.10.2.
Here are some examples for me which shall not be marked as an error or the
documentation does not mention @REV/@PEG at all:
PS D:\Entwicklung\Projekte\toll@repo@test> svn info
Path: .
Working Copy Root Path: D:\Entwicklung\Projekte\toll@repo@test
URL: file:///D:/Entwicklung/Projekte/toll@repo
Relative URL: ^/
Repository Root: file:///D:/Entwicklung/Projekte/toll@repo
Repository UUID: 93f9f50a-2bc4-b345-885e-ec2050f72365
Revision: 9
Node Kind: directory
Schedule: normal
Last Changed Author: mosipov
Last Changed Rev: 9
Last Changed Date: 2018-09-09 12:06:38 +0200 (So, 09 Sep 2018)
PS D:\Entwicklung\Projekte\toll@repo@test> svn mkdir --parents
file:///D:/Entwicklung/Projekte/toll@repo/non/existent@4 -m "dir"
svn: E200009: 'file:///D:/Entwicklung/Projekte/toll@repo/non/existent@4': a peg
revision is not allowed here
PS D:\Entwicklung\Projekte\toll@repo@test> svn export
file:///D:/Entwicklung/Projekte/toll@repo@ ../ex@23
svn: E200009: '../ex@23': a peg revision is not allowed here
This list is not exhaustive, but merely an example of what is wrong. I simply
don't expect any PEG parsing here at all.
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.
As far as I understand the paragraph, it is idiotproof to append the @
to all possible spots and have the issue fixed with thhat?
Michael
