2011/5/23 Mark Phippard <markphip_at_gmail.com>:
> On Mon, May 23, 2011 at 2:24 PM, Daniel Shahaf <d.s_at_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), then it will save you some network
traffic but won't save you from local i/o operation of deleting the
old file and copying a new copy of it from pristine storage. It may be
that it will depend on what network library and protocol will be used.
IIRC Subversion 1.4 server does not know how to skip unwanted data
when serving a sparse working copy, so there might be no way for such
optimizations when operating recent client with your server.
Best regards,
Konstantin Kolinko
Received on 2011-05-23 21:08:19 CEST