Johan Herland <jo...@herland.net>:
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html