Варфоломеев Игорь wrote on Wed, Jul 10, 2013 at 06:40:39 +0400:
> > 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.
>
Fair points. I am sure similar points were made on dev@ when the 'svn
add foo@' problem was discussed there last year (that's part of the
reason I asked you to search for already-filed issues before filing an
issue about add: it's possible we decided to followthe semantics you
describe, so even 'svn add' targets require peg escaping for
consistency).
>
> 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" ?
I don't think you can. Please file a bug.
Workarounds:
- Use copy followed by delete of the source.
Problem: in the future we will implement true renames, which are real
renames distinct from copy+delete. So that's not a good habit to
get into.
- Use the bindings to call svn_client_move() directly, bypssing svn's
peg revision parsing.
Would you be interested in writing patches and/or regression tests for
these issues? See https://subversion.apache.org/patches and
https://svn.apache.org/repos/asf/subversion/trunk/subversion/tests/cmdline/README
Received on 2013-07-10 19:54:34 CEST