Am 2018-09-09 um 23:41 schrieb Daniel Shahaf:
Michael Osipov wrote on Sun, 09 Sep 2018 20:35 +0200:
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.
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.
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.
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
