Re: cvs import

From: Shawn Pearce <spearce@spearce.org>
Date: Sep 14, 2006, 15:50 UTC
Message-ID: <20060914155003.GB9657@spearce.org>
In-Reply-To: <4508EA78.5030001@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> wrote:

>  The only difference between our SCMs that might be difficult
> to paper over in a universal dumpfile is that SVN wants its changesets
> in chronological order, whereas I gather that others would prefer the
> data in dependency order branch by branch.

This really isn't an issue for Git.

Originally I wanted Jon Smirl to modify the cvs2svn code to emit only one branch at a time as that would be much faster than jumping around branches in chronological order. But it turned out to be too much work to change cvs2svn. So git-fast-import (the Git program that consumes the dump stream from Jon's modified cvs2svn) maintains an LRU of the branches in memory and reloads inactive branches as necessary when cvs2svn jumps around.

It turns out it didn't matter if the git-fast-import maintained 5 active branches in the LRU or 60. Apparently the Mozilla repo didn't jump around more than 5 branches at a time - most of the time anyway.

Branches in git-fast-import seemed to cost us only 2 MB of memory per active branch on the Mozilla repository. Holding 60 of them at once (120 MB) is peanuts on most machines today. But really only 5 (10 MB) were needed for an efficient import.

I don't know how the Monotone guys feel about it but I think Git is happy with the data in any order, just so long as the dependency chains aren't fed out of order. Which I think nearly all changeset based SCMs would have an issue with. So we should be just fine with the current chronological order produced by cvs2svn.

-- 
Shawn.