Inconsistencies/bugs in peg revision parsing and help description

[Michael Osipov]

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

Path: .
Relative URL: ^/
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)

'file:///D:/Entwicklung/Projekte/***@repo/non/***@4': 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?

Michael

[Mark Phippard]

Post by Michael Osipov
Folks,
while working on SCM-859 I have found some oddities on Subversion 1.9.7 and 1.10.2.

Path: .
Relative URL: ^/
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)

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:

"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 ***@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 ***@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 ***@."

Mark

[Michael Osipov]

Post by Michael Osipov
Folks,
while working on SCM-859 I have found some oddities on Subversion 1.9.7 and 1.10.2.

Path: .
Relative URL: ^/
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)

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?

Correct.
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

[Mark Phippard]

Post by Michael Osipov

Post by Michael Osipov
Any thoughts?

Correct.
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?
I believe so, yes.

Mark

[Michael Osipov]

Post by Mark Phippard

Post by Michael Osipov

Post by Michael Osipov
Any thoughts?

Correct.
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?

Post by Mark Phippard
I believe so, yes.

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

Michael

[Mark Phippard]

Post by Michael Osipov

Post by Mark Phippard

Post by Michael Osipov

Post by Michael Osipov
Any thoughts?

Correct.
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?

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.

Mark

[Branko Čibej]

Post by Mark Phippard

Post by Michael Osipov

Post by Mark Phippard

Post by Michael Osipov

Post by Michael Osipov
Any thoughts?

Correct.
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.

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.

Post by Mark Phippard

Post by Michael Osipov
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

[Michael Osipov]

Post by Mark Phippard

Post by Michael Osipov

Post by Mark Phippard

Post by Michael Osipov

Post by Michael Osipov
Any thoughts?

Correct.
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?

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

Post by Mark Phippard
export: Create an unversioned copy of a tree.
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

[Daniel Shahaf]

Post by Michael Osipov
I would expect the help output to contain information that target which
parsing and can cause subtile error messages which cannot be explained

Post by Mark Phippard
export: Create an unversioned copy of a tree.
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.

I think you have a point.

In «svn export foo bar», 'foo' is a coordinate in the history — a (path,
revision) tuple — and therefore supports peg revisions. However, that's
not true for 'bar', which is a coordinate in the path space only, and
not even the in-repository path space. For example, one could easily
imagine an 'svn export' syntax in which 'bar' points into an FTP upload
space, or into a git repository, etc.; specifying peg revisions makes no
more sense for unversioned local filesystem paths than for these examples.

A similar argument holds for «svn mkdir baz». In that case, 'baz' is a
coordinate in the repository's path space, but it does not yet exist in
the repository's revision space; there is no (path, revision) tuple for
'baz' and hence no natural value to set the peg revision too.

So, I agree, it would have made sense not to parse peg revisions in
these cases.

That's not to say that we should change now, though. There are
backwards compatibility implications to be considered.

We can, at least, clarify the synopsis. For example:
.
- usage: 1. export [-r REV] URL[@PEGREV] [PATH]
- 2. export [-r REV] PATH1[@PEGREV] [PATH2]
+ usage: 1. export [-r REV] URL[@PEGREV] [UNVERSIONED_PATH[@]]
+ 2. export [-r REV] WC_PATH[@PEGREV] [UNVERSIONED_PATH[@]]
.
where I made two changes: I added a [@] trailer and renamed the
placeholder arguments.

Cheers,

Daniel

[Michael Osipov]

Post by Daniel Shahaf

Post by Michael Osipov
I would expect the help output to contain information that target which
parsing and can cause subtile error messages which cannot be explained

Post by Mark Phippard
export: Create an unversioned copy of a tree.
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.

I think you have a point.
In «svn export foo bar», 'foo' is a coordinate in the history — a (path,
revision) tuple — and therefore supports peg revisions. However, that's
not true for 'bar', which is a coordinate in the path space only, and
not even the in-repository path space. For example, one could easily
imagine an 'svn export' syntax in which 'bar' points into an FTP upload
space, or into a git repository, etc.; specifying peg revisions makes no
more sense for unversioned local filesystem paths than for these examples.
A similar argument holds for «svn mkdir baz». In that case, 'baz' is a
coordinate in the repository's path space, but it does not yet exist in
the repository's revision space; there is no (path, revision) tuple for
'baz' and hence no natural value to set the peg revision too.
So, I agree, it would have made sense not to parse peg revisions in
these cases.

Correct.

Post by Daniel Shahaf
That's not to say that we should change now, though. There are
backwards compatibility implications to be considered.
.
.
placeholder arguments.

That looks like a good comprise, but it does not explain to the user the
purpose of the optional @. Especially because the former optional ARG
says @PEGREV. Do you want to add some reasonable description for that?

One needs to identify further commands having the same problem, e.g.,
'svn cp': target with PEGREV does not make any sense.

Michael