{"thread":{"id":"13705","subject":"parsecvs losing files","startedAt":"2008-05-28T14:50:07Z","lastAt":"2008-05-30T10:08:14Z","messageCount":4,"participants":["Alex Bennee","Pierre Habouzit"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"77937","messageId":"b2cdc9f30805280750v3b92d115yf76f382e5c2fa418@mail.gmail.com","threadId":"13705","inReplyTo":null,"subject":"parsecvs losing files","fromName":"Alex Bennee","fromEmail":"kernel-hacker@bennee.com","sentAt":"2008-05-28T14:50:07Z","receivedAt":"2008-05-28T14:50:07Z","isPatch":false,"sender":{"key":"kernel-hacker@bennee.com","avatar":null},"body":"Hi,\n\nI've been using a daily cron job running parsecvs to convert an uber\nCVS tree into git. It works quite well and is substantially faster\nthan all the other methods I have tried. It also re-creates the same\nhistory every time which is something I haven't managed to do with the\nother tools.\n\nAnyway today I noticed it had failed to import a sub-directory of the\nproject (not a bit I usually build). However looking at the import log\nfrom parsecvs I see that the file was read by parsecvs. It looks as\nthough it should have made it into the git repo. The only thing that\nseems different from the other modules is that the files where\nimported once and don't seem to have been touched since. This may of\ncaused parsecvs to get confused?\n\nQuestions:\n\n1. Has anyone seen this behaviour with parsecvs?\n2. Is there any way to list all the tree objects in a repo so I can\nsearch to see if the files exist in a tree but just not this branch?\n\n-- \nAlex, homepage: http://www.bennee.com/~alex/\n"},{"id":"77952","messageId":"b2cdc9f30805280953l40ce9e37m1fb558e541ef89c3@mail.gmail.com","threadId":"13705","inReplyTo":"b2cdc9f30805280750v3b92d115yf76f382e5c2fa418@mail.gmail.com","subject":"Re: parsecvs losing files","fromName":"Alex Bennee","fromEmail":"kernel-hacker@bennee.com","sentAt":"2008-05-28T16:53:30Z","receivedAt":"2008-05-28T16:53:30Z","isPatch":false,"sender":{"key":"kernel-hacker@bennee.com","avatar":null},"body":"On Wed, May 28, 2008 at 3:50 PM, Alex Bennee wrote:\n> Hi,\n> \n> Anyway today I noticed it had failed to import a sub-directory of the\n> project (not a bit I usually build). However looking at the import log\n> from parsecvs I see that the file was read by parsecvs. It looks as\n> though it should have made it into the git repo. The only thing that\n> seems different from the other modules is that the files where\n> imported once and don't seem to have been touched since. This may of\n> caused parsecvs to get confused?\n\nWell in answer to myself parsecvs does get confused. In an example\nfailed to import file:\n\nLoad: third-party/libxml/runtest.c,v 8207 of 79070\n/export/git/master.cvs/third-party/libxml/runtest.c,v spliced:\n\t 1.1.1.1\n\t 1.1\nSorted heads for /export/git/master.cvs/third-party/libxml/runtest.c,v\n\tmaster 1.1\n\tmaster > BRANCH-3-5-branch 1.1.1.1.0.2\n\tmaster > BRANCH-3-5-16-branch 1.1.1.1.0.4\nbuilding branches for /export/git/master.cvs/third-party/libxml/runtest.c,v\nfile sha1: b694d565caf10fedbc7566f2bf15b893c57d5a19\nfile sha1: b694d565caf10fedbc7566f2bf15b893c57d5a19\nfile has 2 revisions\n\nAn lo, looking at the branches mentioned these missing files are\nthere. Trouble is the files should be in a number of branches, looking\nat the ,v file in question:\n\nhead\t1.1;\nbranch\t1.1.1;\naccess;\nsymbols\n\tBRANCH-3-5-26-1:1.1.1.1\n\tBRANCH-3-5-25-1:1.1.1.1\n\tBRANCH-3-5-24-1:1.1.1.1\n\tBRANCH-3-5-22-3:1.1.1.1\n\tBRANCH-3-5-22-1:1.1.1.1\n\tBRANCH-3-5-21-1:1.1.1.1\n\tBRANCH-3-5-20-1:1.1.1.1\n\tBRANCH-3-5-16-7:1.1.1.1\n\tBRANCH-3-5-19-1:1.1.1.1\n\tBRANCH-3-5-16-6:1.1.1.1\n\tBRANCH-3-5-16-5:1.1.1.1\n\tBRANCH-3-5-18-1:1.1.1.1\n\tBRANCH-3-5-16-4:1.1.1.1\n\tBRANCH-3-5-16-branch:1.1.1.1.0.4\n\tBRANCH-3-5-17-1:1.1.1.1\n\tBRANCH-3-5-16-3:1.1.1.1\n\tBRANCH-3-5-16-2:1.1.1.1\n\tBRANCH-3-5-16-1:1.1.1.1\n\tpost-merge-of-ajz-post-3-5-branch:1.1.1.1\n\tpre-merge-of-ajz-post-3-5-branch:1.1.1.1\n\tBRANCH-3-5-15-1:1.1.1.1\n\tBRANCH-3-5-14-1:1.1.1.1\n\tBRANCH-3-5-branch:1.1.1.1.0.2\n\tBRANCH-3-5-13-1:1.1.1.1\n\tBRANCH-3-5-12-1:1.1.1.1\n\tBRANCH-3-5-11-1:1.1.1.1\n\tBRANCH-3-5-10-1:1.1.1.1\n\tBRANCH-3-5-9-2:1.1.1.1\n\tBRANCH-3-3-20-red-e1-opt-branch:1.1.1.1\n\tGNOME_LIBXML2_2_6_29:1.1.1.1\n\tGNOME:1.1.1;\nlocks; strict;\ncomment\t@ * @;\n\n\n1.1\ndate\t2007.08.16.15.59.35;\tauthor jbpn;\tstate Exp;\nbranches\n\t1.1.1.1;\nnext\t;\n\n1.1.1.1\ndate\t2007.08.16.15.59.35;\tauthor jbpn;\tstate Exp;\nbranches;\nnext\t;\n\n\ndesc\n@@\n\n\n\n1.1\nlog\n@Initial revision\n\n\nI'm not sure why parsecvs got this wrong, I'm digging through it but\nI'm a little fuzzy where lex/bison/whatever is involved. I notice\nlooking at the log for some of the files that did make it that the CVS\nrevisions for all the branches have a .0.[something] suffix which the\nmissing branches in this case don't have. However CVS is very sure the\nfile exists in these other branches.\n\nCould this be something to do with explicit branches and sticky branch\ntags? Or just a straight bug in parsecvs?\n\n\n-- \nAlex, homepage: http://www.bennee.com/~alex/\n"},{"id":"77954","messageId":"20080528170332.GB16996@artemis.madism.org","threadId":"13705","inReplyTo":"b2cdc9f30805280953l40ce9e37m1fb558e541ef89c3@mail.gmail.com","subject":"Re: parsecvs losing files","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-05-28T17:03:32Z","receivedAt":"2008-05-28T17:03:32Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":" Sorry for the top posting but the git list isn't really the upstream\nfor parsecvs. I'm now Cc-ing keithp who is the author :)\n\nOn Wed, May 28, 2008 at 04:53:30PM +0000, Alex Bennee wrote:\n> On Wed, May 28, 2008 at 3:50 PM, Alex Bennee wrote:\n> > Hi,\n> > \n> > Anyway today I noticed it had failed to import a sub-directory of the\n> > project (not a bit I usually build). However looking at the import log\n> > from parsecvs I see that the file was read by parsecvs. It looks as\n> > though it should have made it into the git repo. The only thing that\n> > seems different from the other modules is that the files where\n> > imported once and don't seem to have been touched since. This may of\n> > caused parsecvs to get confused?\n> \n> Well in answer to myself parsecvs does get confused. In an example\n> failed to import file:\n> \n> Load: third-party/libxml/runtest.c,v 8207 of 79070\n> /export/git/master.cvs/third-party/libxml/runtest.c,v spliced:\n> \t 1.1.1.1\n> \t 1.1\n> Sorted heads for /export/git/master.cvs/third-party/libxml/runtest.c,v\n> \tmaster 1.1\n> \tmaster > BRANCH-3-5-branch 1.1.1.1.0.2\n> \tmaster > BRANCH-3-5-16-branch 1.1.1.1.0.4\n> building branches for /export/git/master.cvs/third-party/libxml/runtest.c,v\n> file sha1: b694d565caf10fedbc7566f2bf15b893c57d5a19\n> file sha1: b694d565caf10fedbc7566f2bf15b893c57d5a19\n> file has 2 revisions\n> \n> An lo, looking at the branches mentioned these missing files are\n> there. Trouble is the files should be in a number of branches, looking\n> at the ,v file in question:\n> \n> head\t1.1;\n> branch\t1.1.1;\n> access;\n> symbols\n> \tBRANCH-3-5-26-1:1.1.1.1\n> \tBRANCH-3-5-25-1:1.1.1.1\n> \tBRANCH-3-5-24-1:1.1.1.1\n> \tBRANCH-3-5-22-3:1.1.1.1\n> \tBRANCH-3-5-22-1:1.1.1.1\n> \tBRANCH-3-5-21-1:1.1.1.1\n> \tBRANCH-3-5-20-1:1.1.1.1\n> \tBRANCH-3-5-16-7:1.1.1.1\n> \tBRANCH-3-5-19-1:1.1.1.1\n> \tBRANCH-3-5-16-6:1.1.1.1\n> \tBRANCH-3-5-16-5:1.1.1.1\n> \tBRANCH-3-5-18-1:1.1.1.1\n> \tBRANCH-3-5-16-4:1.1.1.1\n> \tBRANCH-3-5-16-branch:1.1.1.1.0.4\n> \tBRANCH-3-5-17-1:1.1.1.1\n> \tBRANCH-3-5-16-3:1.1.1.1\n> \tBRANCH-3-5-16-2:1.1.1.1\n> \tBRANCH-3-5-16-1:1.1.1.1\n> \tpost-merge-of-ajz-post-3-5-branch:1.1.1.1\n> \tpre-merge-of-ajz-post-3-5-branch:1.1.1.1\n> \tBRANCH-3-5-15-1:1.1.1.1\n> \tBRANCH-3-5-14-1:1.1.1.1\n> \tBRANCH-3-5-branch:1.1.1.1.0.2\n> \tBRANCH-3-5-13-1:1.1.1.1\n> \tBRANCH-3-5-12-1:1.1.1.1\n> \tBRANCH-3-5-11-1:1.1.1.1\n> \tBRANCH-3-5-10-1:1.1.1.1\n> \tBRANCH-3-5-9-2:1.1.1.1\n> \tBRANCH-3-3-20-red-e1-opt-branch:1.1.1.1\n> \tGNOME_LIBXML2_2_6_29:1.1.1.1\n> \tGNOME:1.1.1;\n> locks; strict;\n> comment\t@ * @;\n> \n> \n> 1.1\n> date\t2007.08.16.15.59.35;\tauthor jbpn;\tstate Exp;\n> branches\n> \t1.1.1.1;\n> next\t;\n> \n> 1.1.1.1\n> date\t2007.08.16.15.59.35;\tauthor jbpn;\tstate Exp;\n> branches;\n> next\t;\n> \n> \n> desc\n> @@\n> \n> \n> \n> 1.1\n> log\n> @Initial revision\n> \n> \n> I'm not sure why parsecvs got this wrong, I'm digging through it but\n> I'm a little fuzzy where lex/bison/whatever is involved. I notice\n> looking at the log for some of the files that did make it that the CVS\n> revisions for all the branches have a .0.[something] suffix which the\n> missing branches in this case don't have. However CVS is very sure the\n> file exists in these other branches.\n> \n> Could this be something to do with explicit branches and sticky branch\n> tags? Or just a straight bug in parsecvs?\n> \n> \n> -- \n> Alex, homepage: http://www.bennee.com/~alex/\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"78128","messageId":"b2cdc9f30805300308x2620e34cqca5d55c82e337393@mail.gmail.com","threadId":"13705","inReplyTo":"20080528170332.GB16996@artemis.madism.org","subject":"Re: [WORKAROUND] parsecvs losing files","fromName":"Alex Bennee","fromEmail":"kernel-hacker@bennee.com","sentAt":"2008-05-30T10:08:14Z","receivedAt":"2008-05-30T10:08:14Z","isPatch":false,"sender":{"key":"kernel-hacker@bennee.com","avatar":null},"body":"On Wed, May 28, 2008 at 6:03 PM, Pierre Habouzit wrote:\n> Sorry for the top posting but the git list isn't really the upstream\n> for parsecvs. I'm now Cc-ing keithp who is the author :)\n\nI shall keep CC'ing git@ for visibility if anyone else comes across this :-)\n\n>\n> On Wed, May 28, 2008 at 04:53:30PM +0000, Alex Bennee wrote:\n>> On Wed, May 28, 2008 at 3:50 PM, Alex Bennee wrote:\n>> > Hi,\n>> > \n>> > Anyway today I noticed it had failed to import a sub-directory of the\n>> > project (not a bit I usually build).\n\n>>\n>> Well in answer to myself parsecvs does get confused. In an example\n>> failed to import file:\n>>\n>> Load: third-party/libxml/runtest.c,v 8207 of 79070\n>> /export/git/master.cvs/third-party/libxml/runtest.c,v spliced:\n>> 1.1.1.1\n>> 1.1\n>> Sorted heads for /export/git/master.cvs/third-party/libxml/runtest.c,v\n>> master 1.1\n>> master > BRANCH-3-5-branch 1.1.1.1.0.2\n>> master > BRANCH-3-5-16-branch 1.1.1.1.0.4\n>> building branches for /export/git/master.cvs/third-party/libxml/runtest.c,v\n>> file sha1: b694d565caf10fedbc7566f2bf15b893c57d5a19\n>> file sha1: b694d565caf10fedbc7566f2bf15b893c57d5a19\n>> file has 2 revisions\n>>\n>> An lo, looking at the branches mentioned these missing files are\n>> there. Trouble is the files should be in a number of branches, looking\n>> at the ,v file in question:\n\n>> BRANCH-3-3-20-red-e1-opt-branch:1.1.1.1\n\n>> I notice\n>> looking at the log for some of the files that did make it that the CVS\n>> revisions for all the branches have a .0.[something] suffix which the\n>> missing branches in this case don't have.\n\n\nSo I understand how this has happened. This particular module was\nimported directly into the working branch at the time\n(BRANCH-3-3-20-red-e1-opt-branch) where as other modules where\nimported into the CVS HEAD and then branched into the current working\nbranch. As a result the branch tag didn't have the magic 0 in it.\n\nWe where able to work around the import failure by deleting the branch\ntag from the module and then branching it again. The new branch tag\nbecame:\n\nBRANCH-3-3-20-red-e1-opt-branch:1.1.1.1.0.6\n\nwhich parsecvs was able to correctly parse and assign to the correct\nGIT branch on import. I'm guessing this is a corner case that could do\nwith better handling but in our case it was solved by tweaking our CVS\nrepository.\n\n-- \nAlex, homepage: http://www.bennee.com/~alex/\n"}]}