Re: [PATCH] RFC: git lazy clone proof-of-concept

["Jon Smirl" <jonsmirl@gmail.com>]

On 2/8/08, Jakub Narebski <jnareb@gmail.com> wrote:
> Jan Holesovsky <kendy@suse.cz> writes:
> One of the reasons why 'lazy clone' was not implemented was the fact
> that by using large enough window, and larger than default delta
> length you can repack "archive pack" (and keep it from trying to
> repack using .keep files, see git-config(1)) much tighter than with
> default (time and CPU conserving) options, and much, much tighter than
> pack which is result of fast-import driven import.
>
> Both Mozilla import, and GCC import were packed below 0.5 GB. Warning:
> you would need machine with large amount of memory to repack it
> tightly in sensible time!

A lot of memory is 2-4GB. Without this much memory you will trigger
swapping and the pack process will finish in about a month. Note that
only one machine needs to have this kind of memory. It can be used to
make the optimized pack of the project history and mark it with .keep
files. It doesn't take a lot of memory to use the optimized packs,
only to make them.

There are some patches for making repack work multi-core. Not sure if
they made it into the main git tree yet. These patches work almost
linearly. A eight hour repack will take 2.5 hours on a quad core
machine.

There is very good chance your 1.5GB repo will turn into 300MB if it
is extremely packed. This is something you only need to do once, but
you'll probably end up doing it a dozen times trying to get it just
right.

-- 
Jon Smirl
jonsmirl@gmail.com