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/27 09:36:23 UTC
Slow "move" discourages refactoring.
Hello!
Seemingly simple task like moving folders tree to another location
is very hard with svn. What takes no time on usual file systems -
with svn is heavily dependant on the size of moved directory
contents. And it's /really/ discourages refactoring of repository
structure.
As I remember it was hard under VSS too but I wonder is it an
inherent feature of version control systems? Under what conditions
could it be made /fast/ with current or future versions of svn? Or
the time of "move" will always be "equivalent to a 'copy' and
'delete'"?
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: Slow "move" discourages refactoring.
Posted by John Szakmeister <jo...@szakmeister.net>.
On Thursday 27 November 2003 11:08, Ben Collins-Sussman wrote:
> On Thu, 2003-11-27 at 03:36, Kerim Borchaev wrote:
> > Hello!
> >
> > Seemingly simple task like moving folders tree to another location
> > is very hard with svn. What takes no time on usual file systems -
> > with svn is heavily dependant on the size of moved directory
> > contents. And it's /really/ discourages refactoring of repository
> > structure.
>
> I hope you're not running 'svn move wcpath1 wcpath2'. Because it's
> *not* a move. It's a copy of the whole tree (schedule add), and
> schedule-delete of the old tree.
>
> Just run 'svn move URL1 URL2'. It's near instantaneous, and an O(1)
> operation.
>
I thought the idea was to have related things grouped together on commits. I
mean, moving a directory in my working copy generally implies that I also
need to update some of my build configuration. I'd want that to happen at
the same time so that I don't break trunk. I only say this because I don't
think the URL solution always applies.
-John
---------------------------------------------------------------------
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.
Posted by 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.
Posted by 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
Re[4]: Slow "move" discourages refactoring.
Posted by 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: Re[2]: Slow "move" discourages refactoring.
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2003-11-27 11:00:18 -0600, Ben Collins-Sussman wrote:
> There's nothing advanced about it, nothing scary. Many svn commands are
> designed to use URLs. You need to overcome your fear. Otherwise you're
> going to have a *very* hard time creating branches.
But are there conflict detections on URLs?
For instance, User1 wants to do:
svn move URL1 URL2
But User2 has just done:
svn move URL1 URL3
svn move URL4 URL1
I think that if User1 does a "svn move wcpath1 wcpath2", a conflict
will be detected, as wcpath1 moved to wcpath3 in the repository. But
when using URLs, I don't see how such a conflict can be detected and
the wrong directory (previously URL4) will be moved.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re[2]: Slow "move" discourages refactoring.
Posted by Ben Collins-Sussman <su...@collab.net>.
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.
There's nothing advanced about it, nothing scary. Many svn commands are
designed to use URLs. You need to overcome your fear. Otherwise you're
going to have a *very* hard time creating branches.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re[2]: Slow "move" discourages refactoring.
Posted by Kerim Borchaev <wa...@hotbox.ru>.
Hello Ben,
Thursday, November 27, 2003, 7:08:54 PM, you wrote:
BCS> On Thu, 2003-11-27 at 03:36, Kerim Borchaev wrote:
>> Hello!
>>
>> Seemingly simple task like moving folders tree to another location
>> is very hard with svn. What takes no time on usual file systems -
>> with svn is heavily dependant on the size of moved directory
>> contents. And it's /really/ discourages refactoring of repository
>> structure.
BCS> I hope you're not running 'svn move wcpath1 wcpath2'.
Of course I do 'svn move wcpath1 wcpath2' !!!
BCS> Because it's *not* a move. It's a copy of the whole tree
BCS> (schedule add), and schedule-delete of the old tree.
Yes I know because 'svn help move' tells me this.
BCS> Just run 'svn move URL1 URL2'. It's near instantaneous, and an O(1)
BCS> operation.
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.
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: SPAM[RBL] Re: Slow "move" discourages refactoring.
Posted by Peter Childs <bl...@blueyonder.co.uk>.
On Thu, 27 Nov 2003, Mike Mason wrote:
> Lev Serebryakov wrote:
>
> >
> >BCS> I hope you're not running 'svn move wcpath1 wcpath2'. Because it's
> >BCS> *not* a move. It's a copy of the whole tree (schedule add), and
> >BCS> schedule-delete of the old tree.
> >BCS> Just run 'svn move URL1 URL2'. It's near instantaneous, and an O(1)
> >BCS> operation.
> > Hmmm... But why?! Is it `known bug' or `real feature'? If I want to
> > copy & delete, I could call svn copy & svn delete. And If I want to
> > _move_, I call svn move.
> >
> > Why different ways to point SAME objects (some files via wcpath or
> > same files via URL) lead to different operations? Is here any good
> > reason to have this difference?
> >
> >
>
> They're not the same operation, though. Moving a working copy involves
> copying the files from the server to your working copy, then adding
> them, then submitting them back to the server, which is way more
> expensive than doing everything on the server. Maybe Subversion should
> issue a warning if it thinks you're trying to perform an operation on
> the working copy which really ought to be run on the server.
>
> Mike.
>
No it does not ?
It means
check out into new location
then when you commit
a copy on the repository
delete the orignal.
If you do a copy within you local working copy its a local copy, delete
and a remote copy, delete evetually. Of course if you make any changes the
diff needs to be sent additionally.
Or am I miss understanding the enire problem...
Peter Childs
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
SPAM[RBL] Re: Slow "move" discourages refactoring.
Posted by Mike Mason <mg...@thoughtworks.net>.
Lev Serebryakov wrote:
>
>BCS> I hope you're not running 'svn move wcpath1 wcpath2'. Because it's
>BCS> *not* a move. It's a copy of the whole tree (schedule add), and
>BCS> schedule-delete of the old tree.
>BCS> Just run 'svn move URL1 URL2'. It's near instantaneous, and an O(1)
>BCS> operation.
> Hmmm... But why?! Is it `known bug' or `real feature'? If I want to
> copy & delete, I could call svn copy & svn delete. And If I want to
> _move_, I call svn move.
>
> Why different ways to point SAME objects (some files via wcpath or
> same files via URL) lead to different operations? Is here any good
> reason to have this difference?
>
>
They're not the same operation, though. Moving a working copy involves
copying the files from the server to your working copy, then adding
them, then submitting them back to the server, which is way more
expensive than doing everything on the server. Maybe Subversion should
issue a warning if it thinks you're trying to perform an operation on
the working copy which really ought to be run on the server.
Mike.
---------------------------------------------------------------------
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.
Posted by Francois Beausoleil <fb...@users.sourceforge.net>.
On Fri, 28 Nov 2003 09:30:53 +0300, "Lev Serebryakov"
<le...@serebryakov.spb.ru> said:
> Hello, GMane!
> Friday, November 28, 2003, 2:57:40 AM, you wrote:
>
> G> It sounds like the refactoring that led to this problem is like
> renaming a
> G> Java package, which is a very significant operation.
> BTW, here is a problem. To rename Java or PErl package your need to
> MOVE it and CHANGE FILE. And these operations could not be performed in
> ONE step (revision) now :( So, atomic renaming of package is
> impossible...
Yes, it is possible. But the changes to the files must be done *after*
the move is completed. Idea does this. I don't know about Eclipse.
Remember that a move is an Add + Delete. If Eclipse modifies the file to
be deleted, I don't know if Subversion will copy the modified file
contents. Let's see:
C:\>svn --version
svn, version 0.33.1 (r7789)
compiled Nov 18 2003, 22:27:18
[snip]
C:\>svnadmin create repos
C:\>svn co file:///repos wc
Checked out revision 0.
C:\>cd wc
C:\wc>echo >a.txt this is a test
C:\wc>svn add a.txt
A a.txt
C:\wc>svn ci -m "First version"
Adding a.txt
Transmitting file data .
Committed revision 1.
C:\wc>echo >>a.txt another test, to see if it works
C:\wc>svn move a.txt b.txt
svn: Attempting restricted operation for modified resource
svn: Use --force to override this restriction
svn: Move will not be attempted unless forced
svn: 'a.txt' has local modifications
C:\wc>svn move --force a.txt b.txt
A b.txt
D a.txt
C:\wc>type b.txt
this is a test
another test, to see if it works
So, it looks like the CLI does copy modified text, but will not do so by
default, requiring --force before attempting the operation.
>
> Are here any plans to remove this restriction in future? FS Dump
> can contain two entries for one file (node) in one revision : copy
> and change after that. So, it seems to be possible on low level. But
> svn complains about restricted operation :(
Probably the --force parameter that's missing.
>
> --
> Lev Serebryakov
Hope that helps !
François
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
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.
Posted by GMane <pa...@comcast.net>.
> G> It sounds like the refactoring that led to this problem is like
renaming a
> G> Java package, which is a very significant operation.
> BTW, here is a problem. To rename Java or PErl package your need to
> MOVE it and CHANGE FILE. And these operations could not be performed in
> ONE step (revision) now :( So, atomic renaming of package is
> impossible...
>
> Are here any plans to remove this restriction in future? FS Dump
> can contain two entries for one file (node) in one revision : copy
> and change after that. So, it seems to be possible on low level. But
> svn complains about restricted operation :(
Please note that a move is possible to be done just in a work area
without contacting a server. So, if you're using Eclipse or some other tool
to help with the refactoring, all of the changes will be made just in your
work area. Only when you're done will the changes be committed, atomically,
to the server.
The earlier suggestion to do this with a URL-to-URL move doesn't really
apply here, because the revision that creates wouldn't compile until all
affected files were modified once again to apply the new package name.
Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re[4]: Slow "move" discourages refactoring.
Posted by Lev Serebryakov <le...@serebryakov.spb.ru>.
Hello, GMane!
Friday, November 28, 2003, 2:57:40 AM, you wrote:
G> It sounds like the refactoring that led to this problem is like renaming a
G> Java package, which is a very significant operation.
BTW, here is a problem. To rename Java or PErl package your need to
MOVE it and CHANGE FILE. And these operations could not be performed in
ONE step (revision) now :( So, atomic renaming of package is
impossible...
Are here any plans to remove this restriction in future? FS Dump
can contain two entries for one file (node) in one revision : copy
and change after that. So, it seems to be possible on low level. But
svn complains about restricted operation :(
--
Lev Serebryakov
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re[2]: Slow "move" discourages refactoring.
Posted by GMane <pa...@comcast.net>.
I just want to put in my two cents that we're moving to Subversion
specifically because it *does* encourage refactoring by its great support
for versioning file and directory name/location changes.
It sounds like the refactoring that led to this problem is like renaming a
Java package, which is a very significant operation. That Subversion may be
"slow" in doing this I would not equate with making it "hard" or
"discouraging". If I can tell Eclipse to rename or move a package, have it
do everything without further input, and be able to check in the results
effortlessly at the end, I don't particularly mind if it takes 5 minutes
instead of 15 seconds. The enormous amount of time it is saving over having
to interact manually with a lame VCS system like PVCS is well worth the
wait.
Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re[2]: Slow "move" discourages refactoring.
Posted by GMane <pa...@comcast.net>.
> Hmmm... But why?! Is it `known bug' or `real feature'? If I want to
> copy & delete, I could call svn copy & svn delete. And If I want to
> _move_, I call svn move.
>
> Why different ways to point SAME objects (some files via wcpath or
> same files via URL) lead to different operations? Is here any good
> reason to have this difference?
Probably. If you bear in mind that svn is designed to do many operations
like "svn revert" without needing to contact the repository, you can come up
with good reasons why there might need to be administrative information and
text-base files in both the originating and target directories.
Pat Rusk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re[4]: Slow "move" discourages refactoring.
Posted by Lev Serebryakov <le...@serebryakov.spb.ru>.
Hello Ben,
Thursday, November 27, 2003, 8:05:44 PM, you wrote:
BCS> Subversion has no "true move". It has copy+delete, both in the working
BCS> copy and in the repository. End of story. It is a 95% effective
BCS> solution for many reasons: in the working copy, it makes it easy to
BCS> 'revert' scheduled moves; in the repository, it aligns with our 'cheap
BCS> copy' model.
BCS> Nobody is arguing that a "true move" is a bad idea, however. It's been
BCS> discussed many times before, will require a lot of new design and
BCS> coding, and is definitely a post-1.0 thing.
Thank you for good explanation.
--
Best regards,
Lev mailto:lev@serebryakov.spb.ru
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re[2]: Slow "move" discourages refactoring.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2003-11-27 at 10:18, Lev Serebryakov wrote:
> BCS> Just run 'svn move URL1 URL2'. It's near instantaneous, and an O(1)
> BCS> operation.
> Hmmm... But why?! Is it `known bug' or `real feature'? If I want to
> copy & delete, I could call svn copy & svn delete. And If I want to
> _move_, I call svn move.
Subversion has no "true move". It has copy+delete, both in the working
copy and in the repository. End of story. It is a 95% effective
solution for many reasons: in the working copy, it makes it easy to
'revert' scheduled moves; in the repository, it aligns with our 'cheap
copy' model.
Nobody is arguing that a "true move" is a bad idea, however. It's been
discussed many times before, will require a lot of new design and
coding, and is definitely a post-1.0 thing.
On Thu, 2003-11-27 at 10:28, Leeuw van der, Tim wrote:
> The WC is something which I see in front of me, with my normal tools. To see
> the repository in front of me, I need to open special tools (repos. browser
> in TSVN is the only one that comes to my mind; I don't know if subclipse has
> something similar and I never tried RapidSVN).
How about 'svn ls' ? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re[2]: Slow "move" discourages refactoring.
Posted by Lev Serebryakov <le...@serebryakov.spb.ru>.
Hello Ben,
Thursday, November 27, 2003, 7:08:54 PM, you wrote:
>> Seemingly simple task like moving folders tree to another location
>> is very hard with svn. What takes no time on usual file systems -
>> with svn is heavily dependant on the size of moved directory
>> contents. And it's /really/ discourages refactoring of repository
>> structure.
BCS> I hope you're not running 'svn move wcpath1 wcpath2'. Because it's
BCS> *not* a move. It's a copy of the whole tree (schedule add), and
BCS> schedule-delete of the old tree.
BCS> Just run 'svn move URL1 URL2'. It's near instantaneous, and an O(1)
BCS> operation.
Hmmm... But why?! Is it `known bug' or `real feature'? If I want to
copy & delete, I could call svn copy & svn delete. And If I want to
_move_, I call svn move.
Why different ways to point SAME objects (some files via wcpath or
same files via URL) lead to different operations? Is here any good
reason to have this difference?
--
Best regards,
Lev mailto:lev@serebryakov.spb.ru
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Slow "move" discourages refactoring.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2003-11-27 at 03:36, Kerim Borchaev wrote:
> Hello!
>
> Seemingly simple task like moving folders tree to another location
> is very hard with svn. What takes no time on usual file systems -
> with svn is heavily dependant on the size of moved directory
> contents. And it's /really/ discourages refactoring of repository
> structure.
I hope you're not running 'svn move wcpath1 wcpath2'. Because it's
*not* a move. It's a copy of the whole tree (schedule add), and
schedule-delete of the old tree.
Just run 'svn move URL1 URL2'. It's near instantaneous, and an O(1)
operation.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org