Re: RFC: adding xdelta compression to git

From: Davide Libenzi <davidel@xmailserver.org>
Date: May 3, 2005, 05:30 UTC
Message-ID: <Pine.LNX.4.58.0505022215110.21733@bigblue.dev.mdolabs.com>
In-Reply-To: <Pine.LNX.4.58.0505022131380.3594@ppc970.osdl.org>

On Mon, 2 May 2005, Linus Torvalds wrote:

Show 7 quoted lines

> Yes. EXCEPT for one thing. fsck. I'd _really_ like fsck to be able to know
> something about any xdelta objects, if only because if/when things go
> wrong, it's really nasty to suddenly see a million "blob" objects not work
> any more, with no indication of _why_ they don't work. The core reason may
> be that one original object (that just got used as a base for tons of
> other objects through deltas) is corrupt or missing. And then you want to
> show that _one_ object.

Linus, xdelta-based algorithms already stores informations regarding the object that originated the diff. Since they have no context (like text-based diffs) and are simply based on offset-driven copy/insert operations, this is a requirement. Libxdiff uses an adler32+size of the original object, but you can get as fancy as you like in your own implementation. Before a delta patching, the stored information are cross checked with the input base object, and the delta patch will fail in the eventuality of mismatch. So an fsck is simply a walk backward (or forward, depending on your metadata model) of the whole delta chain.

- Davide