> From: 'Daniel Shahaf' [mailto:d.s_at_daniel.shahaf.name]
> Sent: Wednesday, July 10, 2013 5:45 AM
>
> The question is whether we should not be parsing peg revisions in some
> places. The target arguments to 'add' seem like a clear-cut case. The 'dest'
> argument of move seems like such a case too: assuming Q is a versioned
> directory, what would be the meaning of, say, 'svn move alpha beta gamma
> Q_at_r42'?
This is not my call, of course, I don't see the whole picture.
But, as for me, it's easier to parse peg revision in all cases.
(And throw error if specifying a revision is not supported)
In this case:
* User-interface is more "uniform". User won't need to remember, whether this command is able to handle revision each time.
* If you're writing a wrapper for svn, you would need only one "svn_path = make_svn_path(path,rev)" function.
You won't need to pass any weired additional arguments to it.
* One can imagine, theoretically, that there's a svn command, that is not supporting revision specification first,
but this functionality might be added in next release. So, in case it now "parses peg revision" but it was not
parsing it before - some 3rd party scripts might become incompatible.
* It's harder to get unexpected results.
If user is doing something wrong, he would run into an error message,
which is, often, much better that getting unexpected result.
Anyway, I don't like the way svn move works with @-files:
Both
svn move wc\@2.txt@ wc\A\@2.txt@
and
svn move wc\@3.txt@ wc\A\@3.txt
Provide strange results:
"wc\A\@2.txt@" in first case
"wc\A_at_3.txt" in second case.
(see batch file attached)
But how do I get "wc\A\@4.txt" ?
Received on 2013-07-10 04:49:30 CEST