On Mon, May 23, 2011 at 3:07 PM, Konstantin Kolinko
<knst.kolinko_at_gmail.com> wrote:
> 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),
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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-05-23 21:26:57 CEST