Re: parsecvs losing files

> On Wed, May 28, 2008 at 3:50 PM, Alex Bennee <kernel-hacker@bennee.com> wrote:
> > Hi,
> > <snip>
> > Anyway today I noticed it had failed to import a sub-directory of the
> > project (not a bit I usually build). However looking at the import log
> > from parsecvs I see that the file was read by parsecvs. It looks as
> > though it should have made it into the git repo. The only thing that
> > seems different from the other modules is that the files where
> > imported once and don't seem to have been touched since. This may of
> > caused parsecvs to get confused?
> 
> Well in answer to myself parsecvs does get confused. In an example
> failed to import file:
> 
> Load:                          third-party/libxml/runtest.c,v   8207 of 79070
> /export/git/master.cvs/third-party/libxml/runtest.c,v spliced:
> 	 1.1.1.1
> 	 1.1
> Sorted heads for /export/git/master.cvs/third-party/libxml/runtest.c,v
> 	master 1.1
> 	master > BRANCH-3-5-branch 1.1.1.1.0.2
> 	master > BRANCH-3-5-16-branch 1.1.1.1.0.4
> building branches for /export/git/master.cvs/third-party/libxml/runtest.c,v
> file sha1: b694d565caf10fedbc7566f2bf15b893c57d5a19
> file sha1: b694d565caf10fedbc7566f2bf15b893c57d5a19
> file has 2 revisions
> 
> An lo, looking at the branches mentioned these missing files are
> there. Trouble is the files should be in a number of branches, looking
> at the ,v file in question:
> 
> head	1.1;
> branch	1.1.1;
> access;
> symbols
> 	BRANCH-3-5-26-1:1.1.1.1
> 	BRANCH-3-5-25-1:1.1.1.1
> 	BRANCH-3-5-24-1:1.1.1.1
> 	BRANCH-3-5-22-3:1.1.1.1
> 	BRANCH-3-5-22-1:1.1.1.1
> 	BRANCH-3-5-21-1:1.1.1.1
> 	BRANCH-3-5-20-1:1.1.1.1
> 	BRANCH-3-5-16-7:1.1.1.1
> 	BRANCH-3-5-19-1:1.1.1.1
> 	BRANCH-3-5-16-6:1.1.1.1
> 	BRANCH-3-5-16-5:1.1.1.1
> 	BRANCH-3-5-18-1:1.1.1.1
> 	BRANCH-3-5-16-4:1.1.1.1
> 	BRANCH-3-5-16-branch:1.1.1.1.0.4
> 	BRANCH-3-5-17-1:1.1.1.1
> 	BRANCH-3-5-16-3:1.1.1.1
> 	BRANCH-3-5-16-2:1.1.1.1
> 	BRANCH-3-5-16-1:1.1.1.1
> 	post-merge-of-ajz-post-3-5-branch:1.1.1.1
> 	pre-merge-of-ajz-post-3-5-branch:1.1.1.1
> 	BRANCH-3-5-15-1:1.1.1.1
> 	BRANCH-3-5-14-1:1.1.1.1
> 	BRANCH-3-5-branch:1.1.1.1.0.2
> 	BRANCH-3-5-13-1:1.1.1.1
> 	BRANCH-3-5-12-1:1.1.1.1
> 	BRANCH-3-5-11-1:1.1.1.1
> 	BRANCH-3-5-10-1:1.1.1.1
> 	BRANCH-3-5-9-2:1.1.1.1
> 	BRANCH-3-3-20-red-e1-opt-branch:1.1.1.1
> 	GNOME_LIBXML2_2_6_29:1.1.1.1
> 	GNOME:1.1.1;
> locks; strict;
> comment	@ * @;
> 
> 
> 1.1
> date	2007.08.16.15.59.35;	author jbpn;	state Exp;
> branches
> 	1.1.1.1;
> next	;
> 
> 1.1.1.1
> date	2007.08.16.15.59.35;	author jbpn;	state Exp;
> branches;
> next	;
> 
> 
> desc
> @@
> 
> 
> 
> 1.1
> log
> @Initial revision
> <snip rest of file>
> 
> I'm not sure why parsecvs got this wrong, I'm digging through it but
> I'm a little fuzzy where lex/bison/whatever is involved. I notice
> looking at the log for some of the files that did make it that the CVS
> revisions for all the branches have a .0.[something] suffix which the
> missing branches in this case don't have. However CVS is very sure the
> file exists in these other branches.
> 
> Could this be something to do with explicit branches and sticky branch
> tags? Or just a straight bug in parsecvs?
> 
> 
> -- 
> Alex, homepage: http://www.bennee.com/~alex/
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html