Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.

Martin Langhoff <martin.langhoff@gmail.com>:

You are quite right, but you have misintepreted the subject of my confidence. I am under no illusion that the new cvsimport/cvsps pair is a perfect solution to the CVS-lifting problem, nor even that such a solution is possible.

Thanks, but since I wrote reposurgeon in 2010 I've done more conversions of messy CVS and Subversion repositories than I can easily remember (the Subversion ones being relevant because they often have truly nasty CVS artifacts in their early history). Just off the top of my head there's been gpsd, the Network Utility Tools, Roundup, SSTK2000, the Hercules project, and robotfindskitten. And a raft of smaller projects - I sought them out as torture tests for reposurgeon.

I am therefore intimately, painfully familiar with how bad CVS repos can get. I take it as given that there are still boojums that will perplex my tools lurking out there in the unexplored jungle.

In fact, this very kind of prior experience had been a major
motivation for reposurgeon.  I became convinced several years back
that the batchy design philosophy of conventional repo-conversion
tools was flawed, not flexible enough to deal with the real-world
messes out there.  So I wrote reposurgeon to amplify human judgment
rather than try to replace it.
 
An example of the batchiness mistake close to home is the -m and -M
options in the old version of cvsimport.  It takes human judgment
looking at the whole commit DAG in gitspace to decide what merge
points would best express the (as you say, sometimes ambiguous) CVS
history - what's needed is a scalpel and sutures in a surgeon's hand,
not a regexp hammer.

For extended discussion, see my blog post "Repositories In Translation" at http://esr.ibiblio.org/?p=3859 in which I argue that the process has much more in common with the ambiguity of literary translation than is normally understood.

No, what I am very confident about is the performance and stability of the new cvsps/cvsimport code on *the cases the old code handled* - and a fairly well-defined larger group of many more cases.

My confidence is derived from having built a test suite that incorporates and improves on the git-tree tests. I don't have to merely guess or hope that the new code works better, I can exhibit tests that demonstrate it.

Among my near-term to-do items are applying those tests to cvs2git and parsecvs. But I first need to get parsecvs working again; presently, as I've inherited it, it does not correctly create a HEAD reference in the translated git repo.