You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Lev Serebryakov <le...@serebryakov.spb.ru> on 2003/11/27 16:18:55 UTC
Re[2]: Slow "move" discourages refactoring.
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: 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