cvsimport bug on branches [was: conversion to git]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Eric Blake on 9/19/2007 5:13 PM:

Unfortunately, after publishing this repository, I noticed that there is a bug in git-cvsimport, when a vendor branch is created that contains fewer files than the point it branched from. Those files were not removed from the commit on the new branch, which means the git repository contains too many files compared to what the CVS repository had for any checkout along the branch.

For example, look at the m4-1.4.1 tag.  In CVS,

http://cvs.savannah.gnu.org/viewvc/m4/?root=m4&hideattic=0&pathrev=m4-1_4_1

shows the following: ABOUT-NLS (dead) No revisions exist on m4-1_4_1

and for the file ChangeLog, the predecessor of m4-1_4_1 (rev 1.1.1.1.2.1) was m4-1_4 (rev 1.1.1.1):

http://cvs.savannah.gnu.org/viewvc/m4/ChangeLog?hideattic=0&view=log&root=m4&pathrev=m4-1_4_1

But after git-cvsimport (using git 1.5.3), tag m4-1.4.1 is shown on the branch-1_4 branch, but with unrelated m4-1.4ppre2 as parent, instead of the correct m4-1.4:

http://git.sv.gnu.org/gitweb/?p=m4.git;a=shortlog;h=ab2ce6be

and as a result, the tree includes ABOUT-NLS (which was correctly a part of the m4-1.4ppre2 tag on the master branch):

http://git.sv.gnu.org/gitweb/?p=m4.git;a=tree;h=ab2ce6bec48;hb=ab2ce6bec4

Now that the repository is published, what's the best way to correct the history for the git m4-1.4.1 tag, to correctly pick the m4-1.4 commit as its parent, and to omit the files that were intentionally omitted from the CVS branch it was imported from?

What needs to be done to git-cvsimport to make it recognize files that were omitted from CVS branch creation points, to avoid this problem in the first place?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG8xu684KuGfSFAYARAjd8AJ0eOWw1TFGt4zpQKIDFTGRjxzI/cgCghBpM W91wfRwc8Q2hoMO1WCWYtzM= =zzNR -----END PGP SIGNATURE-----

On Sep 21, 2007, at 3:17 AM, Eric Blake wrote:

git-cvsimport may have more problems, see e.g.

http://marc.info/?l=git&m=118385565913953&w=2 http://marc.info/?l=git&m=118260312708709&w=2

Hard to say. The best is to avoid git-cvsimport if you need to import branches correctly.

And you should do validate the result of any import by comparing a working copy checked out from CVS with a working copy checked out from git.

Never trust the cvs to git importers.

I'd recommend not to use git-cvsimport but better use a different converter.

For me parsecvs [1] works.

I'd also give cvs2svn's git support [2] a try.

cvs2svn strives much harder to report errors and handle complex history correctly. parsecvs for example just crashes on corrupted RCS files, while cvs2svn reports the problem. But if your CVS repository is good parsecvs is much faster.

fromcvs/togit was also mentioned a couple of times on the list. It worked for me the last time I tried it. But I did no in depth validation of the result.

I still believe it would be good to add a warning to the documentation of git-cvsimport and provide links to alternatives.

	Steffen

[1] http://gitweb.freedesktop.org/?p=users/keithp/parsecvs.git [2] http://marc.info/?l=git&m=118592701426175&w=2

On Fri, 21 Sep 2007, Steffen Prohaska wrote:

Yes. git-cvsimport started out as a pretty quick hack, and depends on cvsps which is another fairly hacky thing.

The big advantage of git-cvsimport is that it can do incremental imports, which I don't think the other methods do. But if there is any choice at all, and especially if you're not that interested in the incremental feature (ie you can cut over to git, and perhaps use git-cvsserver to "supprt" CVS users) the other CVS importers are likely to be much better.

			Linus

fredag 21 september 2007 skrev Linus Torvalds:

fromcvs does incremental import and it's very fast and uses much less memory than cvsimport. It needs the rcs files however and will not convert non-branch tags.

-- robin

Hi,

On Fri, 21 Sep 2007, Robin Rosenberg wrote:

Plus you have to install Ruby.  Just wanted people to know.

Ciao, Dscho

fredag 21 september 2007 skrev Johannes Schindelin:

You don't like Ruby, do you? It worth it, really.

-- robin

Hi,

On Fri, 21 Sep 2007, Robin Rosenberg wrote:

No, it's yet another dependency. And the quality of the code still depends on the programmer, not the language.

Ciao, Dscho

fredag 21 september 2007 skrev Johannes Schindelin:

I think I can agree there, on both counts. But, if you want a good incremental CVS importer and have access to the rcs files, that's the one there is.

git-cvsimport has a dependency on cvsps, which isn't included. You have to to look it up yourself chooing among a dozen unequally bad versions. Installing ruby isn't any harder.

The dependency excludes it from being included with Git, but it does not disqualify it as a tool on it's own.

-- robin

On Sep 22, 2007, at 1:16 AM, Robin Rosenberg wrote:

Nonetheless a more detailed description how to install fromcvs would be helpful. I remember it was not obvious to me.

The README of fromcvs only says
'''
Prerequisites:
- ruby (1.8.5 known working)
- fromcvs, <http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs>
- rcsparse, <http://ww2.fs.ei.tum.de/~corecode/hg/rcsparse> (ruby  
module)
- Ruby/RBTree, <http://raa.ruby-lang.org/project/ruby-rbtree/>
- for git: git-fast-import, part of git 1.5
- for db/commitset: sqlite3 + sqlite3-ruby (available as gem)
'''

I didn't use ruby before and had no idea how to install a ruby module or what 'available as gem' means. And by the way, it was not obvious for me that I can download the tip of the mercurial branch by clicking on the 'gz' link at the top of the page.

I think a step by step explanation how to proceed would have helped me.

	Steffen

Steffen Prohaska wrote:

[..]

Could you write down what you had to do and where the problems are as an extension to the current README?

Thanks,
  simon

On 9/22/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

Indeed. And it can take over incrementals on a GIT repo initially imported by parsecvs or cvs2git. That's the recommended practice for tracking non-trivial CVS repos -- IOWs "that's what I do" ;-)

cheers,

m