{"thread":{"id":"4308","subject":"remaining git-cvsimport problems: robustness when cvsps feeds strange history","startedAt":"2006-05-27T12:01:05Z","lastAt":"2006-06-01T21:28:25Z","messageCount":4,"participants":["Yann Dirson","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"20793","messageId":"20060527120105.GL6535@nowhere.earth","threadId":"4308","inReplyTo":null,"subject":"remaining git-cvsimport problems: robustness when cvsps feeds strange history","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-05-27T12:01:05Z","receivedAt":"2006-05-27T12:01:05Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"Since there is quite some activity around git-cvsimport these days, I\nthink I'd raise a couple of issues which are still problematic.\n\nIt should at least issue a warning when cvsps feeds it with a\nbranchpoint that it cannot create because the base branch has not yet\nbeen seen. I am still investigating why cvsps outputs such a buggy\npatchset - it may be a cvs bug at the root, and cvsps probably did not\ndetect an consistency of the cvs data. While there is probably a real\nbug to fix somewhere, git-cvsimport should not silently skip the\nfaulty patchset, especially as it will then miserably fail to import\nany subsequent patch on that branch it ignored this way.\n\nHowever, rerunning the script (after creating a master head by copying\nheads/origin) manages to complete the import: the forgotten branch now\ngets created, and all subsequent patchsets can now be imported.\n\n\nI'm not sure what would be the best way to handle the issue. Maybe it\nwould sufficient to output a bold warning and let the user take the\nnecessary steps to finish the import (since this is after all a bug in\nother tools, which will hopefully be fixed at some point). It could\nalso be useful to raise a flag when detecting that condition, and\nautomatically restart the import process on the first error due to\nthat branch not being available - otoh, that may be overkill, and\ncould possibly miss some other obscure cases.\n\nAs a sidenote, I'm wondering why there is no precise information on\nthe branchpoint in \"cvsps -A\". I guess the semantics are \"fork a new\nbranch from the ancestor one\" at whatever point it currently is - that\nwould look quite risky to me, and could be part of the reason why\ncvsps did not notice the inconsistency: it just did not try to find\nout where the new branch was to be grafted exactly.\n\n======\nPatchSet 1\nDate: 2006/01/03 18:23:53\nAuthor: ydirson\nBranch: HEAD\nTag: (none)\nLog:\nEmpty .cvsignore to be used as a branching base\n\nMembers:\n .cvsignore:INITIAL->1.1\n\n---------------------\nPatchSet 2\nDate: 2006/01/03 18:23:53\nAuthor: ydirson\nBranch: FOO_V3_0_0_HEAD\nAncestor branch: FOO_VENDOR_HEAD\nTag: (none)\nLog:\nfile .cvsignore was added on branch FOO_V3_0_0_HEAD on 2006-05-24 07:51:07\n+0000\n\nMembers:\n .cvsignore:1.1->1.1.4.1(DEAD)\n\n---------------------\nPatchSet 3\nDate: 2006/01/03 18:24:39\nAuthor: ydirson\nBranch: FOO_VENDOR_HEAD\nAncestor branch: HEAD\nTag: FOO_V1_1\nLog:\nImport de FOO 1.1\n---------------------\nPatchSet 20\nDate: 2006/01/10 11:47:54\nAuthor: ydirson\nBranch: FOO_V3_0_0_HEAD\nTag: (none)\nLog:\nfile script.sh was added on branch FOO_V3_0_0_HEAD on 2006-05-24 07:51:08\n+0000\n\nMembers:\n some/script.sh:1.1->1.1.4.1(DEAD)\n===== first import\nFetching .cvsignore v 1.1\nNew .cvsignore: 0 bytes\nTree ID 87556a35bc2c438ede9eb2120c2cdb04baed33ae\nCommitting initial tree 87556a35bc2c438ede9eb2120c2cdb04baed33ae\nCommitted patch 1 (origin 2006-01-03 17:23:53)\nCommit ID 2ddb63602915316e60b26d95414100fd80e602ef\nBranch FOO_VENDOR_HEAD does not exist!\nDelete .cvsignore\n[...]\nTree ID ca6e986b5199b01604dfa459b6e3a2841024f11a\nParent ID 2ddb63602915316e60b26d95414100fd80e602ef\nCommitted patch 3 (FOO_VENDOR_HEAD 2006-01-03 17:24:39)\nCommit ID 9e19f11520c89897704fff252901ff4dc5ae88ad\n[...]\nCommitted patch 19 (origin 2006-01-10 10:47:54)\nCommit ID 0c5063420b769f8db7c009843b3947350bf78eae\nSwitching from origin to FOO_V3_0_0_HEAD\nfatal: Not a valid object name FOO_V3_0_0_HEAD\nread-tree failed: 32768\n===== second run\nskip patchset 1: 1136309033 before 1136890074\nSwitching from master to FOO_V3_0_0_HEAD\nDelete .cvsignore\nTree ID 38b8067e1d36ce7f45bb1121a22628927bfd2ac2\nParent ID b9cf667acd27ba7fd76a405166b355ec51261b17\nCommitted patch 2 (FOO_V3_0_0_HEAD 2006-01-03 17:23:53)\nCommit ID 528efdac6113af50d4c14c3ccabde9661cb19359\nskip patchset 3: 1136309079 before 1136312985\n[...]\nskip patchset 19: 1136890074 before 1136890074\nDelete some/script.sh\nTree ID 38b8067e1d36ce7f45bb1121a22628927bfd2ac2\nParent ID 528efdac6113af50d4c14c3ccabde9661cb19359\nCommitted patch 20 (FOO_V3_0_0_HEAD 2006-01-10 10:47:54)\n[...]\nCommitted patch 409 (origin 2006-05-24 18:59:44)\nCommit ID 74a5c3b1f265f096177120166ae7da1a2cf3f64e\nDONE.\n=====\n--\nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"20798","messageId":"46a038f90605270823qdea766fxcf2327ae0bf7373a@mail.gmail.com","threadId":"4308","inReplyTo":"20060527120105.GL6535@nowhere.earth","subject":"Re: remaining git-cvsimport problems: robustness when cvsps feeds strange history","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-05-27T15:23:01Z","receivedAt":"2006-05-27T15:23:01Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Yann,\n\nI want to see if we can close these gaps. Have you got a public repo\nthat shows this problem so can look more into it?\n\nOn 5/28/06, Yann Dirson wrote:\n> As a sidenote, I'm wondering why there is no precise information on\n> the branchpoint in \"cvsps -A\". I guess the semantics are \"fork a new\n> branch from the ancestor one\" at whatever point it currently is - that\n> would look quite risky to me, and could be part of the reason why\n> cvsps did not notice the inconsistency: it just did not try to find\n> out where the new branch was to be grafted exactly.\n\nIt is perfectly possible for cvs to branch at a \"point\" that is not\nreally a patchset/patchlevel. Just like it is to tag something that\nhas never been a patchset.\n\nIt is something we currently fudge a bit (or a lot, depending on your\npoint of view). If the branch was made on a checkout with an\ninconsistent tree, we cannot really represent that in git matching\nwhat happened in CVS.\n\nOTOH, the cvsps output you are showing us seems to be in the right\norder... patchset 20 should go on top of patchset 3... is cvsimport\ntruly mishandling this?\n\n\n\nmartin\n"},{"id":"20801","messageId":"20060527163555.GM1164@nowhere.earth","threadId":"4308","inReplyTo":"46a038f90605270823qdea766fxcf2327ae0bf7373a@mail.gmail.com","subject":"Re: remaining git-cvsimport problems: robustness when cvsps feeds strange history","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-05-27T16:35:55Z","receivedAt":"2006-05-27T16:35:55Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sun, May 28, 2006 at 03:23:01AM +1200, Martin Langhoff wrote:\n> I want to see if we can close these gaps. Have you got a public repo\n> that shows this problem so can look more into it?\n\nNo, it holds proprietary code - I can only try to reproduce the\nhistory pattern, but I have not succeeded in that yet. And that's not\nsomething I can do on customer time :)\n\n\n> On 5/28/06, Yann Dirson wrote:\n> >As a sidenote, I'm wondering why there is no precise information on\n> >the branchpoint in \"cvsps -A\". I guess the semantics are \"fork a new\n> >branch from the ancestor one\" at whatever point it currently is - that\n> >would look quite risky to me, and could be part of the reason why\n> >cvsps did not notice the inconsistency: it just did not try to find\n> >out where the new branch was to be grafted exactly.\n> \n> It is perfectly possible for cvs to branch at a \"point\" that is not\n> really a patchset/patchlevel. Just like it is to tag something that\n> has never been a patchset.\n>\n> It is something we currently fudge a bit (or a lot, depending on your\n> point of view). If the branch was made on a checkout with an\n> inconsistent tree, we cannot really represent that in git matching\n> what happened in CVS.\n\nYes, I know that too much. I've already thought that it could\npossibly be represented by a merge commit taking as parents all\npatchsets that contain a file revision holding the tag. But such\npatchset synthesis ought to done at cvsps level IMHO.\n\n\n> OTOH, the cvsps output you are showing us seems to be in the right\n> order... patchset 20 should go on top of patchset 3... is cvsimport\n> truly mishandling this?\n\nThat's the problem. I had just copypasted the logs for handling at\nhome, and then I discovered in the cvsps log that the timestamp for\npatchset 2 is the same as the one for patchset 1, which is obviously\nwrong. I'll look at the cvs repo next week to understand whether that\ncomes from the RCS file, or whether it is cvsps misunderstanding\nsomething.\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"21064","messageId":"20060601212825.GO6535@nowhere.earth","threadId":"4308","inReplyTo":"20060527163555.GM1164@nowhere.earth","subject":"Re: remaining git-cvsimport problems: robustness when cvsps feeds strange history","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-06-01T21:28:25Z","receivedAt":"2006-06-01T21:28:25Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sat, May 27, 2006 at 06:35:55PM +0200, Yann Dirson wrote:\n> > OTOH, the cvsps output you are showing us seems to be in the right\n> > order... patchset 20 should go on top of patchset 3... is cvsimport\n> > truly mishandling this?\n> \n> That's the problem. I had just copypasted the logs for handling at\n> home, and then I discovered in the cvsps log that the timestamp for\n> patchset 2 is the same as the one for patchset 1, which is obviously\n> wrong. I'll look at the cvs repo next week to understand whether that\n> comes from the RCS file, or whether it is cvsps misunderstanding\n> something.\n\nThe problem indeed stems from the RCS files themselves. It thus comes\nfrom a bug-or-feature of cvs 1.12.12. This week I have found a number\nof files with such an history in various repos in use at work.\n\nI finally realize I was trying to reproduce the problem at home using\n1.12.9, where the issue does not appear to exist. The following\nscript does show the problem with 1.12.13.\n\nAs you see, a phantom commit is added prior to the resurecting commit\non the branch, and it has the same timestamp as the its dead base\nrevision on the trunk.\n\nIn the logs I had from real repositories with 1.12.12, the \"lines\"\nattribute for the phantom revision was a mirror of the revision\nfollowing it, reflecting no reality at all (would have been \"+0 -1\"\nhere). There is no mention of such a bugfix in the cvs NEWS file, but\nwho knows.\n\nI found no mention of such a feature in the 1.12.9-13 entries in the\nCVS NEWS file, so I doubt that is an intended behaviour - I'll report\na bug on cvs.\n\nHowever, cvsps should surely be made aware of this behaviour, even if\nit is a bug, since being there for at least 2 cvs releases is enough\nto have infected many repositories...\n\n\n==== script\n#!/bin/sh\nset -e\n\n# setup repo and working area\ncvs -d $PWD/root init\nmkdir root/test\ncvs -d $PWD/root co test\ncd test\n\n# trunk\ntouch file1 file2\ncvs add file1 file2\ncvs ci -m \"add files\"\nsleep 2\n\nrm file1 \ncvs rm file1 \ncvs ci -m \"rm file1\"\nsleep 2\n\ncvs tag A\n\n# branch based on trunk\ncvs tag -b A_HEAD\ncvs up -r A_HEAD -P\necho \"stuff and more stuff\" >file1\ncvs add file1\ncvs ci -m \"work\"\nsleep 2\n\ncvsps --norc -x -A\n==== cvs log file1\n----------------------------\nrevision 1.2\ndate: 2006-06-01 23:12:21 +0200; author: dwitch; state: dead; lines: +0 -0; commitid: GyCIctKzKqKVwlzr;\nbranches: 1.2.2;\nrm file1\n----------------------------\nrevision 1.1\ndate: 2006-06-01 23:12:17 +0200; author: dwitch; state: Exp; commitid: j1zLyPu2Bw6Uwlzr;\nadd files\n----------------------------\nrevision 1.2.2.2\ndate: 2006-06-01 23:12:23 +0200; author: dwitch; state: Exp; lines: +1 -0; commitid: D3Fd6f9Wz8cWwlzr;\nwork\n----------------------------\nrevision 1.2.2.1\ndate: 2006-06-01 23:12:21 +0200; author: dwitch; state: dead; lines: +0 -0; commitid: D3Fd6f9Wz8cWwlzr;\nfile file1 was added on branch A_HEAD on 2006-06-01 21:12:23 +0000\n====\n\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"}]}