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

Re: [PATCH] Skip-deltas, for review

From: William Uther <will+_at_cs.cmu.edu>
Date: 2002-07-27 17:31:36 CEST

On 27/7/02 3:45 AM, "Greg Hudson" <ghudson@MIT.EDU> wrote:

> So, in the long run, the average delta crosses lg(N) node-revisions.
> I'm really bothered by this result; lg(1024) is 10, after all, and I
> don't want to expand people's repositories by an order of magnitude
> unless they really want that. That's an absolute worst case, of course;
> a delta across N revisions is generally much less than N times the delta
> across one revision, because of reduced overhead and overlap between the
> deltas. None of my tests, artificial or natural, saw anything
> approaching a 2x increase in space, much less 10x. (The artificial test
> with the single monotonically shrinking file saw a space increase of
> 20%; sorry that I mistakenly said 5-10% earlier.)

I'd be interested to see real-world comparisons. What happens to the size
of that GCC repos? I think we'll do much better than the asymptotic case on
real world data. As you said in a previous mail:

> * A lot of files stabilize by the time they reach 32 node-revisions,
> and those files experience no cost.

The full log(N) space increase is only on files that are increasing linearly
in size (or otherwise changing EVERY revision in such a way that the deltas
don't reduce in size when combined). I don't know many files that do that.
Even change-logs get truncated and rotated, and that would solve the

Even if this does happen on a single file in a repos. Is log(N) on a single
file that much?

> When it comes to commit time, I remain unconcerned:

[snip: factor of 2 speed change at commit time]

Great :).


\x/ill :-}

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 27 17:32:08 2002

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.