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

Jeff King <peff@peff.net>:

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.