Importing from CVS issues

Hi,

We've been having issues with CVS for some time and I thought I'd give git a spin. To do some like-for-like tests I'm having a go at importing our cvs repository into git so I can do some benchmarks on things like branch creation as well as play around with the visualisation tools.

Obviously the CVS repo is non-trivial as we have many branches (one per change developed). I've been trying to import script but it seems to falling over. For starters cvsps is spitting out lots of messages along the lines of:

WARNING: revision 1.3.2.1 of file scripts/xmltools/t/runtests.pl on
unnamed branch

Before the import script finally dies with:

WARNING: revision 1.3.2.1 of file
scripts/xmltools/t/data/gzip/DO-NOT-BACKUP on unnamed branch
DONE; creating master branch
cp: cannot stat `/export/test/cvstogit/.git/refs/heads/origin': No such
file or directory
usage: git-read-tree (<sha> | -m [-u] <sha1> [<sha2> [<sha3>]])

Is this a just a case of the cvsps not giving output the script can deal with? Any suggestions on how I can proceed with diagnosing what went wrong?

-- Alex, homepage: http://www.bennee.com/~alex/ Barometer, n.: An ingenious instrument which indicates what kind of weather we are having. -- Ambrose Bierce, "The Devil's Dictionary"

I haven't seen this problem myself. There are some recent patches Junio merged that handle some oddities better. Give the 'pu' branch a go if you can.

I take it that the repo is not public. I'd like to try and reproduce the problem. Can you get it to happen with a public repository?

For debugging, I'd say proofread the cvsps output, see ~/.cvsps/#repo . that could give you hints as to the 'nameless' branches. Why is origin missing is a different problem.

Ah! Important: if you're adding debugging statements by hand, bear in mind that part of the code is executed in a forked child process, and prints there will mess things up.

cheers,

martin

On Tue, 2005-08-16 at 23:26 +1200, Martin Langhoff wrote:

I'll look at that in a bit. I already picked up a few of the patches mentioned on the list.

I'm afraid not. However I think I've found a problem when I tried running cvsps on its own to generate the patchset. It seems that REV_STR_MAX (cvsps-2.1/cvsps_types.h) wasn't big enough to contain some of our version strings.

This will be a feature of our development process which means all changes are based of branches, some of which branch multiple times and live for a long time before code is merged into the mainline. I don't know if any open source projects use CVS in such a way.

My import seems to be getting a lot further now. I now just need to clean out the corrupted files that are breaking cvs log.

-- Alex, homepage: http://www.bennee.com/~alex/ New systems generate new problems.

Alex Bennee <kernel-hacker@bennee.com> writes:

Was this done with an empty destination dir? I've seen similar things happen in a dir where an interrupted cvs import was done previously, and the 'origin' branch was never created.

On Tue, 2005-08-16 at 14:16 +0200, David Kågedal wrote:

Yes, in fact I let the script create the new destination dir. So I don't think its an issue with stale data from a previous attempt being left around.

-- Alex Bennee - alexjb@transitive.com "The world is beating a path to our door" -- Bruce Perens, (Open Sources, 1999 O'Reilly and Associates)