[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SPAM[RBL] Re: Slow "move" discourages refactoring.

From: Peter Childs <blue.dragon_at_blueyonder.co.uk>
Date: 2003-11-27 17:50:27 CET

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
Received on Thu Nov 27 17:50:07 2003

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.