Re: RFC: New diff-delta.c implementation

From: Junio C Hamano <junkio@cox.net>
Date: Apr 22, 2006, 17:03 UTC
Message-ID: <7v3bg5k0ev.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <81E2B4A6-3591-418D-9448-47648AF4A687@adacore.com>

Geert Bosch <bosch@adacore.com> writes:

Show 11 quoted lines

> On Apr 22, 2006, at 08:51, Nicolas Pitre wrote:
>> First, pack-objects tries to find the best object combinations
>> producing the smallest delta.  Then there is a second pass
>> where the best delta are actually written out.  When that
>> message appears that means the delta size for the same object
>> pair does not match between those two passes.
>
> OK, thanks for that info. There are very few comments in the
> code, or specs of either the file format used, or
> for function arguments. I'll look a the code again with this
> info.

Initially I thought it would be irrelevant to your work, but generating packs is the only way to really exercise the diff-delta code these days; Documentation/technical/pack-format.txt might help.

> What is the exact role of the max_size parameter that is
> passed to diff_delta? I took it to mean return 0 if
> the size of the delta would be bigger than max_size and
> max_size is nonzero.

No, that is a _strong_ hint to tell diff_delta to quit early without wasting cycles if the result exceeds the given size, either because we already have a delta smaller than that, or because we expect to get an undeltified representation compressed down to that size. So if your algorithm cannot notice early stage of the processing if the result would exceed that max_size, just code things to ignore it first.