On 09.09.2018 14:20, Mark Phippard wrote:
> On Sep 9, 2018, at 8:15 AM, Michael Osipov <michaelo_at_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_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?
>> 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.
Indeed. The interpretation of paths and URLs in the command-line must be
consistent, regardless of the command context. That makes the code
simpler, but more importantly, it makes it easier to educate users. (Or
at least, ideally it would make it easier ...).
Adding exceptions here just because parsing peg revisions appears
redundant in some places is definitely not the way we want to go.
>> 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.
And a hint: use the bindings if you want to be explicit about peg
revisions. The @ in paths is only special in the command-line client,
not in the underlying APIs.
-- Brane
Received on 2018-09-09 18:22:36 CEST