Re: CVS -> SVN -> Git

Eric S. Raymond wrote:

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.

Could you give a quick summary of the relevant differences between CVS
and RCS files in this context?  Then I'd be happy to try to figure out
how bad the situation still is today, and whether it can be easily improved.

[...]
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.

Other people have complained about having to convert from SVN to
distributed SCMs, because the SVN model doesn't map so easily to their
favorite.

You are basically suggesting that an SVN repository is the best lingua
franca of the SCM world, which I don't believe.  The CVS history *does*
have to be deformed a bit to fit into SVN, and an svn2xxx converter
would have to undo the deformation.

My idea is not to built (for example) cvs2git; rather, I'd like cvs2svn
to be split conceptually into two tools:

cvs2<abstract_description_of_cvs_history>, whose job it is to determine
the most likely "true" CVS history based on the data stored in the CVS
repository, and

<abstract_description_of_cvs_history>2svn

Then later write

<abstract_description_of_cvs_history>2git
<abstract_description_of_cvs_history>2hg

etc.

The first split is partly done in cvs2svn 2.0.  And I naively imagine
that writing the new output back ends won't be all that much work.

Michael