Re[4]: Slow "move" discourages refactoring.

[Kerim Borchaev <wa...@hotbox.ru>]

Hello Ben,

Thursday, November 27, 2003, 8:00:18 PM, you wrote:

BCS> On Thu, 2003-11-27 at 10:43, Kerim Borchaev wrote:

>> For such an ordinary svn user like me working with URLs(except with
>> root rep URL like for 'svn checkout') feels too "advanced" and
>> therefore dangerous and scary.

BCS> There's nothing advanced about it, nothing scary.  Many svn commands are
BCS> designed to use URLs.  You need to overcome your fear.
Now I /see/ that I need to use "url-move".
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>   Otherwise you're going to have a *very* hard time creating branches.
I won't be creating branches;-)

Best regards,
 Kerim                            mailto:warkid@hotbox.ru



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re[6]: Slow "move" discourages refactoring.

[Kerim Borchaev <wa...@hotbox.ru>]

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

Re: Re[4]: Slow "move" discourages refactoring.

[Ben Collins-Sussman <su...@collab.net>]

On Thu, 2003-11-27 at 11:19, Kerim Borchaev wrote:

> Now I /see/ that I need to use "url-move".

You don't *have* to use url-moves.  Nobody's forcing you.  You just need
to understand that working-copy-moves are O(N), and repository moves are
O(1).  You can choose your inconvenience:  is it more inconvenient to
figure out the proper URLs to use, or is it more inconvenient to wait
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?

Run 'svn info' on any working copy path.  It will tell you the
repository URL it represents.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org