Subject: Re: CVS -> SVN -> Git

From: [email-masked] (Eric S. Raymond)
Date: Sat, 14 Jul 2007 15:52:52 -0400

Michael Haggerty <[email-masked]>:
> Martin Langhoff wrote:
> > On 7/14/07, Michael Haggerty <[email-masked]> wrote:
> >> Incidentally, now that cvs2svn 2.0.0 is nearly out, I am thinking about
> >> what it would take to write some other back ends for cvs2svn--turning
> >> it, essentially, into cvs2xxx.  Most of the work that cvs2svn does is
> >> inferring the most plausible history of the repository from CVS's
> >> sketchy, incomplete, idiomatic, and often corrupt data.  This work
> >> should also be useful for a cvs2git or cvs2hg or cvs2baz or ...
> > 
> > Great to hear that. I'm game if we can do something in this direction
> > - surely we can make it talk to fastimport ;-)
> 
> We added some hooks to cvs2svn 2.0 to start working in this direction.

Excuse me, I missed Michael's Haggerty's original post. But as it
happens I've been doing quite a lot of work with VCSes and migration
tools recently and I have some opinions and experience that I think are
relevant.

In slightly more detail: I just finished forward-porting sccs2rcs to
Python, I've been moving some Subversion-hosted stuff to Mercurial,
and I've been thinking about writing a simple rcs2svn because the last
time I tried using cvs2svn on a large RCS history (the Jargon File, as
it happens, a couple years back) it did a very poor job of coalescing
related commits without the CVS metadata.  I'm going to hope 2.0.0 has
fixed that; I'll experiment and see.

Also, I'm in the process of rewriting Emacs VC mode and testing it
with three different VCSes. One consequence is that the Subversion
support in Emacs is going to cease sucking badly in the very near
future -- the VC-mode rewrite is giving VC mode the ability to make
atomic fileset commits if the underlying VCS will support them.  I'm
putting the finishing touches on that code today, as it happens.

Another consequence is that Mercurial and git support will get really
good, oh, about ten minutes after the new Subversion backend lands.
The blocker on all three was the same weakness in the engine of VC
mode, for whicch I was (alas) responsible as its original author and
*which I have now fixed*.

So, I hear about plans to make cvs2svn generate something other than
Subversion, and here's my instant reaction:

	    	       	   DON'T DO IT!

This is not because I think Subversion is some kind of final answer to the
VCS problem.  Fame from it -- I'm moving towards Mercurial.  No, the
real reason I think this would be a waste of time is subtler than that.

Subversion, by design, is very good at capturing the metadata from
SCCS and RCS and the various CVS variants floating around.  In fact,
lifting from those into Subversion is basically lossless - the real
problems are that (a) as Michael notes, the data you're losslessly
lifting is scratchy, and (b) as I've noted, you have to use heuristics
to coalesce file histories into changesets and those don't always make
the links they should.

That being the case, two-step conversion with tools that import CVS to
SVN and export from SVN to whatever actually works extremely well.
I'm speaking from direct recent experience here, not just theory. In
fact, it works so well well that I'm convinced a tool for direct
conversion from CVS to the third-generation systems would be misplaced
effort.  

I'd much rather see the effort go into improving import to Subversion
from CVS and older, cruftier systems.  Subversion is like the Heinlein quote
about low Earth orbit being halfway to anywhere -- once your code and 
metadata are there, export to advanced alien VCSes is easy.  So, Michael;
I know it's nice to think about building space probes that can go direct 
to the aliens -- but please concentrate on building a better heavy-lift 
vehicle, because low earth orbit is the hard part.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>