Johan Herland <johan@xxxxxxxxxxx>: > HOWEVER, this only solves the "cheap" half of the problem. The reason > people want incremental CVS import, is to avoid having to repeatedly > convert the ENTIRE CVS history. This means that the CVS exporter must > learn to start from a given point in the CVS history (identified by > the above mapping) and then quickly and efficiently convert only the > "new stuff" without having to consult/convert the rest of the CVS > history. THIS is the hard part of incremental import. And it is much > harder for systems like CVS - where the starting point has a broken > concept of history... I know of *no* importer that solves what you call the "deep" part of the problem. cvsps didn't, cvs-fast-import doesn't, cvs2git doesn't. All take the easy way out; parse the entire history, and limit what is emitted in the output stage. Actually, given what I know about delta-file parsing I'd say a "true" incremental CVS exporter would be so hard that it's really not worth the bother. The problem is the delta-based history representation. Trying to interpret that without building a complete set of history states in the process (which is most of the work a whole-history exporter does) would be brutally difficult - barely possible in principle maybe, but I wouldn't care to try it. It's much more practical to tune up a whole-history exporter so it's acceptably fast, then do incremental dumping by suppressing part of the conversion in the output stage. cvs-fast-export's benchmark repo is the history of GNU troff. That's 3057 commits in 1549 master files; when I reran it just now the whole-history conversion took 49 seconds. That's 3.7K commits a minute, which is plenty fast enough for anything smaller than (say) one of the *BSD repositories. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> -- 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