> On Mon, May 23, 2011 at 3:07 PM, Konstantin Kolinko > <knst.koli...@gmail.com> wrote: > > 2011/5/23 Mark Phippard <markp...@gmail.com>: > >> On Mon, May 23, 2011 at 2:24 PM, Daniel Shahaf > <d...@daniel.shahaf.name> wrote: > >>> Bob Archer wrote on Mon, May 23, 2011 at 13:54:59 -0400: > >>>> I can't imagine that this would need to move the file over the > network > >>>> since it all happens server side. Although, I guess when you > do an > >>>> update it might bring the file down again rather than doing a > local > >>>> move/rename. > >>> > >>> update used to rely on copyfrom information to fetch just the > delta for > >>> moves/copies it had already had the base for, but we removed > that > >>> feature recently for other reasons. > >>> > >>> (I hope other can fill in the details --- such as why we > removed it and > >>> what releases will be affected --- I don't remember them > offhand ): ) > >> > >> I think Bob is just saying that if you move a file via its URL > that > >> nothing needs to transfer over the network. He acknowledges > that it > >> "might" when you do update again. I would note that if you move > a > >> file locally, it also does not have to send it over the network > when > >> you perform the commit. So it is actually probably cheaper to > do it > >> locally than on the server if you only have one working copy. > >> > >> The feature removed in 1.7 was that on update SVN could > sometimes move > >> a file locally rather than download it again. It was removed > because > >> due to the way SVN editor drives work, the feature only worked > in > >> certain situations (when the copy was sent to the client before > the > >> delete) and apparently the feature was just complicating the > working > >> copy code for what amounted to a hack with small benefits. > If/when > >> SVN grows a true rename feature it would have to be implemented > >> properly. > >> > > > > Ed, > > > > In svn 1.7 there is pristine storage area in the working copy, > where > > all present files are stored by their checksums. If I understand > this > > pristine storage correctly, if you move a file remotely on the > server > > (svn mv URL URL) then when you update your working copy and both > old > > and new paths are in the same working copy, Subversion will find > the > > file in its pristine storage and won't re-download it over > network. If > > what I wrote is true (I have not verified whether this actually > works > > this way, but I have some hopes), > > AFAIK, this sort of feature was not in scope for 1.7, but it is > exactly the sort of feature that the WC rewrite will enable for > future > versions. Especially imagine some future version that lets you > share > a single pristine store across all your WC's. You could checkout > trunk twice and the second one would not even need to transfer any > files from the server.
Nice but isn't a pristine = base? how would this work if the two working copies had different BASE revisions? 1.7 should be able to locally move a file, but unfortunately even 1.7.0 isn't going to have a "moved" action is it? It will still look like a delete/add to the client? BOb
