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

Alex Bennee [off-list ref] writes:

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

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.

-- 
David Kågedal

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

Alex Bennee [off-list ref] writes:

quoted

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

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.

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)

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

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'll look at that in a bit. I already picked up a few of the patches
mentioned on the list.

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?

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.