Sorry for the top posting but the git list isn't really the upstream for parsecvs. I'm now Cc-ing keithp who is the author :) On Wed, May 28, 2008 at 04:53:30PM +0000, Alex Bennee wrote: > On Wed, May 28, 2008 at 3:50 PM, Alex Bennee <kernel-hacker@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpdUjzJMW4xl.pgp
Description: PGP signature
