You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Kerim Borchaev <wa...@hotbox.ru> on 2003/11/28 09:57:09 UTC
Re[6]: Slow "move" discourages refactoring.
Hello.
Actually it's all good news. Remember I even supposed that a slow
move is an "inherent feature of version control systems".
Now it took me (only) 40 min to create an 'svnmove.py SCRPATH
DSTPATH' command that work "like" 'svn move SCRPATH DSTPATH' but
with corresponding urls.
But 'svn update' after url-move is O(N) anyway - it A-dds new
files and D-eletes the old:
svnmove.py _tests tests
...
svn update
...
A tests\...
A tests\...
D _tests
But it's nice to know that at least server-side move is O(1).
Best regards,
Kerim mailto:warkid@hotbox.ru
Thursday, November 27, 2003, 8:32:59 PM, you wrote:
BCS> On Thu, 2003-11-27 at 11:19, Kerim Borchaev wrote:
>> Now I /see/ that I need to use "url-move".
BCS> You don't *have* to use url-moves. Nobody's forcing you. You just need
BCS> to understand that working-copy-moves are O(N), and repository moves are
BCS> O(1). You can choose your inconvenience: is it more inconvenient to
BCS> figure out the proper URLs to use, or is it more inconvenient to wait
BCS> O(N) time for the copy to happen?
>> Could you suggest how to make an utility(say 'svnmove') that would be
>> used like 'svn move' with /paths/ but internally converting them to
>> /proper/ urls(deducing them from current working dir) and calling 'svn
>> move'(or the like) with those urls?
BCS> Run 'svn info' on any working copy path. It will tell you the
BCS> repository URL it represents.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org