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

Re: large number of large binary files in subversion

From: Mark Phippard <markphip_at_gmail.com>
Date: Mon, 23 May 2011 14:30:44 -0400

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

Mark Phippard
Received on 2011-05-23 20:31:10 CEST

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

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