Re: Figured out how to get Mozilla into git

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Jun 10, 2006, 01:23 UTC
Message-ID: <46a038f90606091823u45dd3dffsc584c0d4e0128b4c@mail.gmail.com>
In-Reply-To: <9e4733910606091317p26d66579mdf93db293f93fb50@mail.gmail.com>

On 6/10/06, Jon Smirl <jonsmirl@gmail.com> wrote:

> The git tree that Martin got from cvsps is much smaller that the git
> tree I got from going to svn then to git.  I don't why the trees are
> 700KB different, it may be different amounts of packing, or one of the
> conversion tools is losing something.

Don't read too much into that. Packing/repacking points make a _huge_ difference, and even if one of our trees is a bit corrupt, the packsizes should be about the same.

(With the patches I sent you we _are_ choosing to ignore a few branches that don't seem to make sense in cvsps output. These will show up in the error output -- what I saw were very old, possibly corrupt branches there, stuff I wouldn't shed a tear over, but it is worth reviewing).

Show 6 quoted lines

> I haven't come up with anything that is likely to result in Mozilla
> switching over to git. Right now it takes three days to convert the
> tree. The tree will have to be run in parallel for a while to convince
> everyone to switch. I don't have a solution to keeping it in sync in
> near real time (commits would still go to CVS). Most Mozilla
> developers are interested but the infrastructure needs some help.

Don't worry about the initial import time. Once you've done it, you can run the incremental import (which will take a few minutes) even hourly to keep 'in sync'.

> Martin has also brought up the problem with needing a partial clone so
> that everyone doesn't have to bring down the entire repository. A
> trunk checkout is 340MB and Martin's git tree is 2GB (mine 2.7GB).  A
> kernel tree is only 680M.

Now that I have managed to repack the repo, it is indeed back in the 600M range. Actually, I just re-repacked, it took under a minute, and it shrank down to 607MB.

Yay.

I'm sure that if you git-repack -a -d on a machine with plenty of memory once or twice, we'll have matching packs.

cheers,

martin