Keith Packard <keithp@xxxxxxxxxx> wrote: > On Wed, 2006-09-13 at 15:52 -0700, Nathaniel Smith wrote: > > > Regarding the basic dependency-based algorithm, the approach of > > throwing everything into blobs and then trying to tease them apart > > again seems backwards. What I'm thinking is, first we go through and > > build the history graph for each file. Now, advance a frontier across > > the all of these graphs simultaneously. Your frontier is basically a > > map <filename -> CVS revision>, that represents a tree snapshot. > > Parsecvs does this, except backwards from now into the past; I found it > easier to identify merge points than branch points (Oh, look, these two > branches are the same now, they must have merged). Why not let Git do that? If two branches are the same in CVS then shouldn't they have the same tree SHA1 in Git? Surely comparing 20 bytes of SHA1 is faster than almost any other comparsion... > However, this means that parsecvs must hold the entire tree state in > memory, which turned out to be its downfall with large repositories. > Worked great for all of X.org, not so good with Mozilla. Any chance that can be paged in on demand from some sort of work file? git-fast-import hangs onto a configurable number of tree states (default of 5) but keeps them in an LRU chain and dumps the ones that aren't current. -- Shawn. - 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