Announcing cvs-fast-export 1.0

Not long ago I pulled the plug on one of the two CVS export utilities I was maintaining. One consequence of this is that I decided I needed to get the other one out of beta and into a state I would be willing to ship as 1.0.

And lo, it has come to pass. I just shipped cvs-fast-export 1.0. It has been well field-tested; a couple of weeks ago I used it to rescue the history of Gnu Troff.

There are several CVS exporters out there that suck pretty badly. (To be fair, the perversity of CVS is such that doing an even half-decent job of lifting CVS histories into a modern version-control system is quite difficult.) Now that this one is shipped I know of exactly two that don’t suck. The other one is Michael Haggerty’s cvs2git, which I’m working with him on improving.

Tradeoffs: cvs2git is slow and a bit clunky to use (I’m improving the latter but can’t fix the former). cvs-fast-export is blazingly fast (like, 3.7K commits a minute) but has a hard repository-size limit – above it you run out of core and the OS reaps the process in mid-flight. (Very few projects will hit this limit.)

For each tool there are weird CVS edge cases that it gets wrong. The sets of edge cases are different. cvs2git’s may be smaller, but I’m not sure of that; we haven’t set up head-to-head testing yet. Most projects will not trip over either set of problems.

cvs-fast-export is better documented, especially around error conditions.

Help stamp out CVS in our lifetime!

5 thoughts on “Announcing cvs-fast-export 1.0

  1. I’d settle for getting more projects to use version control in the first place. I don’t know how to do that.

  2. You seem to be implying that cvs2git is close enough to O(1) memory use and cvs-fast-export definitely isn’t. But I wouldn’t call the resulting problem a “hard” limit, since it can be raised by throwing more computer at the problem. After all, these days even laptops are 64-bit if they are new. It’s just a matter of supplying enough terabyte hard drives for swap — although depending on cvs-fast-export’s locality, it might then lose a race with cvs2git due to thrashing.

    Speaking of 64-bit, there’s one thing I’ve been waiting for a chance to bring up. Some time ago you published an essay “World Domination 201″, arguing that the transition to 64-bit was an important one-time opprotunity to beat Windows (which you recommended abandoning some free-software purity to capitalize on). IMHO, that essay is currently lacking a final addendum discussing how things actually turned out, now that the “hard deadline” of 2008 is six years in the past.

    Also, I’d say four months from now there will be a new point of vulnerability for Windows that will be more significant than the 64-bit transition — the ending of security updates for Windows XP. People who sneer at Windows 7 as an inefficient XP emulator (the other releases supported after April being much worse) will be forced to give WINE a chance.

  3. > IMHO, that essay is currently lacking a final addendum discussing how things actually turned out, now that the “hard deadline” of 2008 is six years in the past.

    We didn’t make the nut. The *next* technology transition, however – the one where smartphone descendants take over as the dominant devices – looks like the one we’re going to win.

  4. I used cvs-fast-export to convert a Savannah website to github.io, and I made what’s hopefully my last ever serious use of “cvs commit” on Jan 1, 2014. It brings me a special kind of perverse joy with the idea that I may never use CVS again.

    There was nothing particularly special about the repository, only around 30 commits all made by myself; still, it is nice to say “good bye, and good ridance” about CVS.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">