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.
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
Received on 2018-09-09 23:42:09 CEST