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
Received on Fri Nov 28 10:57:59 2003