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
Received on 2018-09-10 22:24:16 CEST