Sylvain Beucler wrote: > On Mon, Oct 25, 2010 at 10:44:00PM +0200, Jim Meyering wrote: >> Sylvain Beucler wrote: >> >> > On Mon, Oct 25, 2010 at 10:30:13PM +0200, Jim Meyering wrote: >> >> Sylvain Beucler wrote: >> >> > Do you know about concurrency? I.e. need we make the repo read-only >> >> > for developers when we're doing such a repack? >> >> >> >> >From what I recall, that's not necessary. >> >> I think (probably a gross simplification) it creates a big pack of >> >> whatever's on hand, and then flips a ref (atomic rename) to make the new >> >> pack's objects live, and then removes the packed (and now logically >> >> unlinked) objects at its leisure. Any new objects that came in while >> >> packing are simply not packed. >> > >> > I guess I'll try on a copy of the Gnash repo. >> > >> > It seems there's some kind of special condition in that project >> > though, I don't get nearly the same ratio on my projects (admittedly >> > not nearly as active either :)). >> >> Those numbers are typical of a large project that's been converted from >> e.g., cvs, and whose repository has never been properly compressed. > > I committed during various phases of the 'gc' (counting, compressing, > writing), all the commits were kept, just not packed. > > I'll optimize the real gnash.git right now - lots of b/w saved :)
Beware that if you use pack.threads=0 or a value that's too large, repacking that repo may run out of memory. When I did it on an 8-core system with 4GiB of RAM, it failed until I limited it to 2 cores. > Speaking of git, there are messages from cvs2git piling up in the mail > system, due to no alias defined for cvs2git, which is now done. I > think you disabled the emacs cvs->git repo but not the cron. Thanks for the heads up. I've just turned that off.
