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

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

Martin Langhoff <martin.langhoff@gmail.com>:
> I dealt with enough CVS repos to see that the branch point could be
> ambiguous, and that some cases were incurably ugly and ambiguous.

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.

> My best guess is that you haven't dealt with enough ugly CVS repos. I
> used to have the old original X.org repos, but no more. Surely
> Mozilla's fugly old CVS repos are up somewhere, and may be
> therapeutic.

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.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>