Am 2018-09-09 um 14:20 schrieb Mark Phippard:
On Sep 9, 2018, at 8:15 AM, Michael Osipov <micha...@apache.org> wrote:
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.
After sending my last reply, it occurred to me that if there were not a common parser and
a consistent set of rules then it would make your "simple workaround" a lot
more difficult to use. You would have to be aware on a command by command basis what the
rules were and when you need to add an @ and when you had to not do that. I would not be
surprised if that sort of discussion happened back when this feature was added ... which
was many years ago now.
Do you think it is worthwhile to file some issues about the incorrect help
output?
I would recommend posting here on what the specific changes are that you think
ought to be made. I did not understand from your original post what you were
suggesting was incorrect. Having the command transcripts was nice but you did
not really highlight where you thought there were problems.
I would expect the help output to contain information that target which
do not explicitly have [@PEGREV] documented are still subject to peg rev
parsing and can cause subtile error messages which cannot be explained
via help:
export: Create an unversioned copy of a tree.
usage: 1. export [-r REV] URL[@PEGREV] [PATH]
2. export [-r REV] PATH1[@PEGREV] [PATH2]
1. Exports a clean directory tree from the repository specified by
URL, at revision REV if it is given, otherwise at HEAD, into
PATH. If PATH is omitted, the last component of the URL is used
for the local directory name.
2. Exports a clean directory tree from the working copy specified by
PATH1, at revision REV if it is given, otherwise at WORKING, into
PATH2. If PATH2 is omitted, the last component of the PATH1 is used
for the local directory name. If REV is not specified, all local
changes will be preserved. Files not under version control will
not be copied.
If specified, PEGREV determines in which revision the target is first
looked up.
PATH and PATH2 are not subject to @PEGREV.
Michael
