This repository has been archived on 2017-04-03. You can view files and clone it, but cannot push or open issues/pull-requests.
blog_post_tests/20141105235038.blog

11 lines
2.5 KiB
Plaintext

Chipping away at CVS
<p>I&#8217;ve just shipped a new version of <a href="http://www.catb.org/esr/cvs-fast-export/">cvs-fast-export</a>, 1.26. It speeds the tool up more, more, more &#8211; cranking through 25 years and 113300 commits of Emacs CVS history, for example in 2:48. That&#8217;s 672 commits a second, for those of you in the cheap seats.</p>
<p>But the real news this time is a Python wrapper called &#8216;cvsconvert&#8217; that takes a CVS repository, runs a conversion to Git using cvs-fast-export, and then &#8211; using CVS for checkouts &#8211; examines the CVS and git repositories side by side looking for translation glitches. It checks every branch tip and every tag.</p>
<p>Running this on several of my test repos I&#8217;ve discovered some interesting things. One such discovery is of a bug in CVS. (Yeah, I know, what a shock&#8230;)</p>
<p><span id="more-6498"></span></p>
<p>CVS uses the RCS state field value of &#8220;dead&#8221; to mark files that have been deleted. I found a case in the CVS repo of a project called &#8220;timidity&#8221; where a file had somehow ended up with state dead at rev 1.2, Exp (the default live state) at 1.3, and dead again at its final revision of 1.4. This confused CVS badly; a checkout keyed to a tag made after 1.3 but before 1.4 should have included the file but did not. </p>
<p>This showed up as a defect (mismatched file manifests) in cvsconvert. I spent half a day looking for where cvs-fast-export had gone wrong before I figured out that cvs-fast-export was doing what the metadata in the master said it should &#8211; it was CVS that had screwed the pooch. Annoying, but not very surprising.</p>
<p>This was an example of the most common kind of defect &#8211; files that had been deleted in CVS showing up under tags in gitspace when they didn&#8217;t under the corresponding CVS tags. Maybe eventually I&#8217;ll figure out how to perfectly match CVS&#8217;s behavior here, but it&#8217;s not really a big deal &#8211; there tend to be only a few of these per CVS repository and a few minutes&#8217; work with reposurgeon will snip them off nicely.</p>
<p>Reassuringly, I found no cases anywhere of manifest mismatches or file differences at master or any other branch tip. Well, other than some trivial file differences due to CVS keyword expansion, and those can be suppressed.</p>
<p>The design approach of cvsconvert seems quite successful. I may try writing something parallel to it to sanity-check Subversion lifts.</p>