[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: svn move and <at> sign in filepath

From: Варфоломеев Игорь <i3v_at_mail.ru>
Date: Wed, 10 Jul 2013 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.

Anyway, I don't like the way svn move works with @-files:
svn move wc\@2.txt@ wc\A\@2.txt@
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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.