Re: [PATCH 3/3] docs/cvs-migration: mention cvsimport caveats

["Eric S. Raymond" <esr@thyrsus.com>]

Jeff King <peff@peff.net>:
>               I am not qualified to write on the current state of
> the art in CVS importing.

I *am* qualified; cvs-fast-export has had a lot of work put into it by
myself and others over the last five years.  Nobody else is really
working this problem anymore, not much else than cvs2git is even left
standing at this point. Most other attempts on the problem have
stalled or flamed out, and were never very robust in dealing with
repository malformations to begin with.

cvs2git can probably still almost match cvs-fast-export in ability to handle
pathological cases, but is painfully slow by comparison.  (Part of that is
implementation in Python vs. C.)

cvs-fast-export has been successfully performance-tuned for very large
repositories, such as the entirety of NetBSD, and is orders of
magnitude faster than it used to be. (I parallelized the parsing
of RCS masters with a re-entrant Bison instance running per thread;
this makes a huge difference on large repositories, for which that
stage dominates running time.) Its ability to recover sense from
repository malformations was already pretty good five years ago
and is probably unmatched now.  It does .cvsignore conversion.

cvs-fast-export also now has a really good test suite collecting all
kinds of weird CVS deformations from the field, and a wrapper that can
both do a conversion and check for correctness at every tag as well as
the tip revision.

By contrast, the wrapper/cvsps combination git ships continues to be
disgracefully bad and should be scrapped - remember that I maintained
cvsps for a while and tried to EOL it because its branch-resolution
algorithms are unsound.  I have a replacement wrapper ready any time
the git maintainer decides to stop shipping broken, dangerous code.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>