On 8/18/06, Nicolas Pitre <nico@xxxxxxx> wrote:
A better way to get such a size saving is to increase the window and depth parameters. For example, a window of 20 and depth of 20 can usually provide a pack size saving greater than 11% with none of the disadvantages mentioned above.
Our window size is effectively infinite. I am handing him all of the revisions from a single file in optimal order. This includes branches. He takes these revisions, runs xdiff on them, and then puts the entire result into a single zlib blob. I suspect the size reduction is directly proportional to the age of the repository. The kernel repository only has three years worth of data in it. Linus has the full history in another repository that is not in general distribution. We can get it from him when he gets back from vacation. If the repository doesn't contain long delta chains the optimization doesn't help that much. On the other hand it doesn't hurt either since the chains weren't long. My repository is four times as old as the kernel one and I am getting 4x the benefit. This is a good format for archival data that is infrequency accessed. That is why I proposed a two pack system. One pack would contain the archival data and be highly optimized for size and the second pack would contain recent changes and be optimized for speed. The size optimization is important for controlling bandwidth costs. -- Jon Smirl jonsmirl@xxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html