Re: [PATCH] git-cvsimport-script: parse multidigit revisions

On Wed, 13 Jul 2005, Matthias Urlichs wrote:

Hmm.. I finally tried to import the bkcvs kernel tree into git, and while I'm cursing the slowness of CVS (I'm _hoping_ that part of the problem is just that CVS is especially slow with old versions of files, and that the import will eventually start speeding up), there's definitely something wrong going on with new files in an archive...

In particular, they always end up being imported as zero-sized empty files, and will be filled in only later if that file is ever touched again. In other words, the resulting git tree ends up being bogus.

The command line I used was

	git cvsimport -d /home/torvalds/bkcvs -p --bkcvs linux-2.5

and I wonder if it's the "--bkcvs" thing that confuses cvsimport, but I also wonder if anybody has actually tried this before. With or without the --bkcvs line, I get

	Argument "28213 has collisions" isn't numeric in addition (+) at /home/torvalds/bin/git-cvsimport-script line 600, <CVS> line 1.
	* UNKNOWN LINE * PatchSet 28209 has collisions
	* UNKNOWN LINE * PatchSet 28194 has collisions
	* UNKNOWN LINE * PatchSet 28181 has collisions
	* UNKNOWN LINE * PatchSet 28180 has collisions
	...

Sadly, since I don't know perl, I can't tell whether this is a problem with cvsps on the kernel, or the cvsimport perl script. I'm going to try my old hacky C + shell alternative next just to see, but I thought I'd ask whether people have tried this before and already know what's wrong.

Btw, looking at what the perl script _seems_ to do, it does seem to do insane things for the local CVS archive case. As far as I can tell from the spaghetti that is perl, it uses a CVS server to handle even the local file case, which just _can't_ be right. I realize you'd want to do that to avoid connecting millions of times, but maybe it's better to use something like cvsnup to download the whole thing, and then always use a local CVS archive?

			Linus