Re: Balanced packing strategy

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Nov 14, 2005, 10:24 UTC
Message-ID: <200511141124.35429.Josef.Weidendorfer@gmx.de>
In-Reply-To: <W4340426396265721131944586@webmail12>

On Monday 14 November 2005 06:03, Craig Schlenter wrote:

Show 11 quoted lines

> Hi
> 
> > From: Josef Weidendorfer [mailto:Josef.Weidendorfer@gmx.de]
> > [snip]
> > AFAICS, the git native protocol (which is nothing more than a pack itself
> > for each transfer) even has this problem, too: If you are updating every
> > day via git native, the sum of transfered bytes in a month will be a
> > multiple of one git transfer for all the month's changes.
> 
> Interesting ... is this because in a bigger pack the compression will
> be better as there is probably more stuff to "delta" against?

No, it is because of the self-containment of git packs: Deltas (storing differences instead of full file content) are only allowed to other objects in the same pack. The self-containment is a safety measure: you do not want to have dependencies to the outside, because this would destroy the contents of a pack by changing/removing another file.

So if the changes of a day are 100 oneliners to different files, the pack has to contain the full content of the 100 files. With incremental packing, you would probably add only the 100 oneliners (ie. deltas) at end of the pack, because the full file contents have to be in the pack if there was a change to them recorded in the pack previously. And this probability is higher if the pack contains a larger history of the project.

Back to the example: By doing a git transfer every day, you always will transfer the full contents of files which where changed on this day, because git protocol transfers self-contained packs.

Josef