subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Варфоломеев Игорь <>
Subject RE: svn move and <at> sign in filepath
Date Wed, 10 Jul 2013 02:40:39 GMT
> From: 'Daniel Shahaf' []
> 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@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)"
	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@3.txt" in second case.

(see batch file attached)

But how do I get "wc\A\@4.txt" ?

View raw message