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

Re: Rep sharing and circular deltas

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 27 Mar 2008 16:23:26 -0400

Karl Fogel wrote:
>> being unchanged. However, with rep-sharing, we get:
>>
>> +-------------------------+
>> v |
>> +-----+ +-----+ |
>> | | delta | | delta +-+
>> | | ----> | | ----> |o|
>> | | | | +-+
>> +-----+ +-----+
>> A_1 A_2 A_3
>>
>> Where both A_1 and A_2 remain unchanged, and A_3, instead of being a new
>> representation, just refers to the previously written identical
>> representation, A_1. This turns out to be a problem, because A_3 is
>> really just A_1, which is a delta against A_2, which is a delta against
>> A_1, which is a delta against A_2, ad nauseam.
>>
>> See the problem?
>
> Well, no, wait. Under a sharing scheme, if when you add a string you
> discover it has the same (fulltext) checksum as some existing string,
> then no new deltification happens -- instead, the new string is just a
> reference to the existing string. No cycle danger here.
>
> In other words, both A1 and A3 would be deltas against A2.
>
> I didn't read the rest of the mail closely, because it seemed to be
> solving a problem whose existence I'm denying here :-).

Deltification happens in a separate phase of the commit, Karl. By the time
we perform deltification, we've completely forgotten that we recycled a
representation/string somewhere along the way and should avoid deltifying
against that object.

Trust me, this problem *does* exist. Compile the fs-rep-sharing code with
BDB support right now, and run the test suite. But, uh, save your Emacs
buffer state before doing so.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-03-27 21:23:40 CET

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.