Re: CVS -> SVN -> Git

[Scott Lamb <slamb@slamb.org>]

Michael Haggerty wrote:
> One quick-and-dirty idea that I had was to have cvs2svn output
> information compatible with cvsps's output, as I believe that several
> tools rely on cvsps to do the dirty work and so could perhaps be
> persuaded to use cvs2svn out of the box.

I think this would be an excellent approach. The interface between
cvs->X (cvsps), Y->git (git-fastimport), and cvs->git glue
(git-cvsimport) is a great idea for troubleshooting and for code sharing
with other converters. (Shawn O. Pearce's attitude is a great example of
this - he can maintain the part he cares about and several converters
benefit even though he's never used them.)

However, I was unhappy to see that cvsps doesn't reuse any cvs2svn code
or unit tests. I remember seeing a lot of those hairy cases on the
Subversion list long ago, so a CVS converter without those tests seems
untrustworthy. If I maintained an important CVS repository I wanted to
convert to git accurately, I would use cvs2svn.py+git-svnimport over
git-cvsimport any day.

They both seem much better than something like Tailor, though. I've
discovered several things that made me realize going through working
copies is error-prone (as well as slow).

>> Does cvs2svn handle incremental imports, remembering any "guesses"
>> taken earlier? Last time I looked at it, it had far better logic than
>> cvsps, but it didn't do incremental imports, and repeated imports done
>> at different times would "guess" different branching points for new
>> branches, so it _really_ didn't support incrementals
> 
> That's correct; cvs2svn does not support incremental conversion at all
> (at least not yet).

That's an important feature for me. I'm using git-cvsimport to track
other people's CVS repositories. Initial import is SLOW and
resource-intensive on the network, client, and server, so I couldn't
switch to anything that didn't support incremental use.

Best regards,
Scott

-- 
Scott Lamb <http://www.slamb.org/>