Solving the CVS-lifting problem
<p>Last month I added CVS-reading support to reposurgeon.  The reason I haven&#8217;t blogged in ten days is that this pulled me down a rathole out of which I am just now beginning to emerge. And now I have a a request for help &#8211; I need to collect some perverse CVS repositories, preferably relatively small ones.</p>
<p><span id="more-4745"></span></p>
<p>Y&#8217;all might <a href="http://esr.ibiblio.org/?p=4738">recall</a> that the program I adopted as a CVS-repository-reading front end was cvsps, after I had hacked it to emit a git fast-import stream.  Sadly, cvsps (which had been basically untouched by its former maintainer since 2008) turned out not only to have a whole bunch of unintegrated fix patches pending, but to be seriously buggy even after those were applied. There was a showstopper in the branch-analysis code that would often put gitspace branch points at the wrong place to represent the CVS history, and attribute files added just before the join to the wrong branch.  Ugly stuff.</p>
<p>The worst bugs are fixed now, and I can prove it, because I built a regression-test suite and have been adding bug cases to it. But the process basically forced me to rewrite the cvsimport tool in the git suite.  It uses cvsps, and it relies an ancestry-tracking option that I had to remove because it was broken.  On top of that, testing revealed that git-cvsimport was itself a source of several kinds of conversion bugs which my new export code entirely eliminated.</p>
<p>So, then I had to do a round of politics to sell that fix to Junio Hamano and the git list.  That negotiation seems to be done now; I expect to be able to ship a patch tomorrow that will be merged with a minimum of fuss.  Alas, though, CVS is not yet done with me. Because through a peculiar accident I&#8217;m now the maintainer of yet another CVS lifter, parsecvs.</p>
<p>parsecvs is the code my occasional friend and ally Keith Packard &#8211; one of the co-designers of X &#8211; wrote to lift the X repositories from CVS to git.  I found out when I was looking for a CVS-reading front end that Keith had abandoned it after it got its job done, after which it got picked up by somebody named Bart Massey who lost interest in it in turn.  I had written them explaining that I wanted to dust it off turn it into something that could ship a fast-import stream to standard output.</p>
<p>Bart and Keith were radio silent, so I found cvsps, did a bunch of fixups, and its maintainer (Dave Mansfield) dropped it in my lap. Then, a week later, Bart gets back to me to convey me that he&#8217;s lost interest and I should probably take over parsecvs.</p>
<p>OK, now I have a duty.  Both of these dusty hunks of code have fallen into my hands; I should figure out which one can do a better job, polish it up, and publicly end-of-life the other one so nobody puts future effort into a dead end.  Which is when I started thinking about writing a CVS torture test.</p>
<p>Now my goal is to assemble a rogue&#8217;s gallery of CVS perversities, then test them against cvsps, parsecevs, *and* cvs2git (the spinoff of cvs2svn).  Use the test to pick a winner by objective success, then end-of-life anything I&#8217;m maintaining that lost and pour my effort into improving the winner.</p>
<p>Though, actually, there&#8217;s another possible outcome for parsecvs; even if it doesn&#8217;t do CVS as well as one of the other two, it does collections of RCS files without CVS metadata. In one possible future, I test parsecvs against the Ruby rcs-fast-export maintained by Giuseppe Bilotta, which can only do RCS collections that are either multi-branch or multi-file but not both.  If parsecvs turns out to be better, I&#8217;ll make the case to Giuseppe that the Ruby rcs-fast-export should be EOLed and replaced with a renamed parsecvs.</p>
<p>Anyway, this is a general request for the location of perverse and nasty CVS repositories that I can snarf and add to my torture test.  Bonus points if they&#8217;re relatively small.</p>
