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

Re: Bigger --deltas dump with 1.7.5 than with 1.6.17

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Tue, 26 Jun 2012 12:57:27 -0600

On Sat, Jun 23, 2012 at 9:15 AM, Branko Čibej <brane_at_apache.org> wrote:
> On 23.06.2012 00:23, Vincent Lefevre wrote:
>> Thanks for the explanations.
>>
>> On 2012-06-22 00:18:50 +0200, Stefan Fuhrmann wrote:
>>> xdelta uses fixed-size 100kByte deltification windows.
>>> The Changelog file in question is >400k, i.e. 4+ windows.
>>> You insert about 2k at the beginning of the file, moving
>>> the older parts by a similar distance. At the beginning
>>> of each delta window, those 2+k don't have deltification
>>> partner. Expected delta size: > 4 x 2kBytes.
>> Wouldn't it be possible to change this size of deltification windows,
>> with a command-line option (for svnadmin dump) and/or an option in
>> the config file?
>>
>> The gain would be quite important on some kinds of changes (typically
>> ChangeLog update), and a dump of a revision is something that could
>> be done once and for all, so that it would be worth to spend time on
>> optimizing it.
>
> It's not that simple, unfortunately. Currently both the delta generator
> and especially the delta combiner expect the windows to be a known,
> constant size. You can't just change them without affecting a /lot/ of code.
>
> Frankly I don't know how to make all the delta code paths gracefully
> deal with variable window sizes. I'm sure it can be done, but the ROI at
> this point is not good at all.

It's a shame that we didn't include the window size in the encoding of
xdelta windows back in the day. Oh, well, a lesson for the future, I
suppose.

-Hyrum

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2012-06-26 20:58:01 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.