Re: cvs2git

Francis Galiegue wrote:

I don't like to reinvent the wheel and you have gone a lot further than I did
wrt cvs2git, with the added advantage that you work on a physical CVS tree
and you know a LOT more about CVS than I do. And I do, indeed, have physical
access to "my" CVS tree.

Even for the few people who don't have physical access to their CVS
tree, there is a solution [1].  I don't think this is a significant
issue, and indeed we've had very few complaints about this over the years.

I wish that cvs2svn[2git] gets things as right as possible, and am willing to
help in any way possible.

The first step is to send in bug reports (including sample repositories)
for anything you think can be improved.  It is very easy to produce a
test case from even a proprietary repository [2].

Have you ever had a look at git-cvsimport already? Not my code, it relies on
cvsps, which is flawed, that's a given fact. But it builds a state-of-the-art
git repository.

How do you define "state-of-the-art"?  Granted, the resulting git
repository is simpler than the one created by cvs2git, but that is
because *it is typically wrong*.  The tool produces simple output
because it assumes away so much of the true complexity that can be
recorded in a CVS history.

I am not interested in a known-to-be-incorrect conversion, no matter how
pretty it looks in gitk.

git-cvsimport is *broken*, and the only way to fix it is to give it (and
its output) all of the complexity of cvs2svn/cvs2git.  I know that for a
fact because cvs2svn used to be based on simpler algorithms (though even
then not as naive as those used by cvsps!) and we were constantly trying
to patch up this or that edge case in a futile struggle against a system
that was fundamentally broken.  The switch to the current
topological-based changeset creation fixed all such bugs at once.

If you try to build a robust and correct tool on cvsps, you are doomed
to failure because (1) cvsps can crash complex CVS repositories and (2)
cvsps doesn't even *try* to supply all information correctly, e.g.
regarding the true contents of tags and branches [3].

By now, I have achieved the first part of my project (correctly parsing the
cvsps cache file), next step I'll "lighten" the git-cvsimport source (bug for
bug compatibility to start with).

Please believe me, because I have years of suffering behind me:

1. cvsps is broken and not useful for this purpose

2. "parsing the cvsps cache file" is an absolutely minuscule part of
writing a CVS -> anything converter.  You think you're making good
progress, but you have no idea of what you are getting into.  Read [4]
and really think about whether you want to reimplement a comparable set
of features from scratch.  And remember that many of these features are
not optional bells and whistles; they are *needed for correctness*.

One thing is that this program uses bare git commands, not the fast-import
way.

This will absolutely kill performance for a large repository.  There is
a discussion of this issue in our mailing list archives and probably
also on the git mailing list.

Hence my first question: if I lighten git-cvsimport code, will that help
you for cvs2git?

If I polish up my roller skates, will that help you fix your car? ;-)

Michael

[1] http://cvs2svn.tigris.org/faq.html#repoaccess
[2] http://cvs2svn.tigris.org/faq.html#testcase
[3] http://selenic.com/pipermail/mercurial-devel/2008-February/004975.html
[4] http://cvs2svn.tigris.org/features.html