On Thu, 29 Jun 2006, Nicolas Pitre wrote: > > The negative delta cache concept is certainly attractive even for normal > repositories, especially for public servers, since when used in > conjonction with delta reuse it makes the creation of a pack basically > free. So I think this idea really has merits, as long as the cache > remains small. I don't really see much of a point of this all. Instead of having a separate cache, wouldn't it be much better to just take the hint from the previous pack-file? In the repacking window, if both objects we are looking at already came from the same (old) pack-file, don't bother delta'ing them against each other. That means that we'll still always check for better deltas for (and against!) _unpacked_ objects, but assuming incremental repacks, you'll avoid the delta creation 99% of the time. Ie somethng really simple like the appended. Linus --- diff --git a/pack-objects.c b/pack-objects.c index bed2497..cea63e7 100644 --- a/pack-objects.c +++ b/pack-objects.c @@ -988,6 +988,13 @@ static int try_delta(struct unpacked *tr return -1; /* + * We do not bother to try a delta that we discarded + * on an earlier try + */ + if (trg_entry->in_pack && trg_entry->in_pack == src_entry->in_pack) + return -1; + + /* * If the current object is at pack edge, take the depth the * objects that depend on the current object into account -- * otherwise they would become too deep. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Fri Jun 30 07:04:58 2006
This archive was generated by hypermail 2.1.8 : 2006-06-30 07:05:31 EST