{"thread":{"id":"32678","subject":"git-cvsimport-3 and incremental imports","startedAt":"2013-01-20T20:09:22Z","lastAt":"2013-01-21T14:07:19Z","messageCount":16,"participants":["John Keeping","Eric S. Raymond","Jonathan Nieder","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"207328","messageId":"20130120200922.GC7498@serenity.lan","threadId":"32678","inReplyTo":null,"subject":"git-cvsimport-3 and incremental imports","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-01-20T20:09:22Z","receivedAt":"2013-01-20T20:09:22Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"I've now spent some time looking at git-cvsimport-3.py from\njc/cvsimport-upgrade and made some progress in making it pass more of\nthe Git test suite (my work in progress is at [1]).\n\nHowever, I think there is a fundamental problem with the way it handles\nincremental imports and I'm hoping someone with more git-fast-import\nexperience can point me in the right direction.\n\nCurrently, cvsps-3 never writes a \"from ...\" line in the first commit it\noutputs for a branch, even when the output is restricted by date (i.e. a\ncontinuation of a previously imported branch), which results in failure\nto update branches since git-fast-import is run without \"--force\". If I\nmake a simple modification so that it does this, it can end up\noutputting an empty commit (a duplicate of the current tip commit on the\nbranch).\n\nGiven that the start date for the import is currently just read from\nHEAD there is probably scope for this being worse on other branches if\nthey have more recent commits than the current branch.\n\nI don't think there is any way to solve this without giving cvsps more\ninformation, probably the last commit time for all git branches, but\nperhaps I'm missing a fast-import feature that can help solve this\nproblem.\n\n\n[1] https://github.com/johnkeeping/git/tree/cvsimport-3\n\n\nJohn\n"},{"id":"207342","messageId":"20130120232008.GA25001@thyrsus.com","threadId":"32678","inReplyTo":"20130120200922.GC7498@serenity.lan","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2013-01-20T23:20:08Z","receivedAt":"2013-01-20T23:20:08Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"John Keeping :\n> I don't think there is any way to solve this without giving cvsps more\n> information, probably the last commit time for all git branches, but\n> perhaps I'm missing a fast-import feature that can help solve this\n> problem.\n\nYes, you are. The magic incantation is\n\n from refs/heads/^0\n\nI've just pushed a cvsps-3.9 with an -i option that generates these at\neach branch root. Combine it with -d and you get incremental\nfast-export.\n\nYou get to integrate this. I think the transition strategy Junio\nhas chosen is seriously mistaken, leading to unnecessary grief for users\nwho will be fooled into thinking it's OK to still use cvsps-2.x. Because\nI do not wish to encourage or endorse this mistake and am tired of arguing\nagainst stubborn determination to do the wrong thing, I am not going to \nsink more effort into the git project's end of the CVS-lifting problem.\nThere are too many better uses for my time.\n-- \n\t\tEric S. Raymond\n"},{"id":"207343","messageId":"20130120233422.GB3474@elie.Belkin","threadId":"32678","inReplyTo":"20130120232008.GA25001@thyrsus.com","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-20T23:34:22Z","receivedAt":"2013-01-20T23:34:22Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Eric S. Raymond wrote:\n\n> You get to integrate this. I think the transition strategy Junio\n> has chosen is seriously mistaken, leading to unnecessary grief for users\n> who will be fooled into thinking it's OK to still use cvsps-2.x.\n\nSo our choices are:\n\n a. support current users, offend ESR, don't benefit from ESR\n improvements\n\n b. give up on current users, please ESR, benefit from ESR\n improvements\n\n c. some option yet undiscovered\n\nIn that case, (c) sounds like our best bet. Do I understand\ncorrectly?\n\nSigh,\nJonathan\n"},{"id":"207344","messageId":"20130120234205.GC3474@elie.Belkin","threadId":"32678","inReplyTo":"20130120232008.GA25001@thyrsus.com","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-20T23:42:05Z","receivedAt":"2013-01-20T23:42:05Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Eric S. Raymond wrote:\n\n> You get to integrate this. I think the transition strategy Junio\n> has chosen is seriously mistaken, leading to unnecessary grief for users\n> who will be fooled into thinking it's OK to still use cvsps-2.\n\nAh, I missed a detail on first reading. I think there has been a\nsmall misunderstanding.\n\nJunio proposed a transition strategy, but I don't think it's fair to\nsay he has chosen it without discussion or is imposing it on you. If\nyou or someone else comes up with a better transition strategy, you\nare free to completely ignore Junio's proposal. If the affected users\ngenerally prefer your alternate proposal, in my experience that means\nit will be integrated.\n\nHoping that clarifies a little,\nJonathan\n"},{"id":"207345","messageId":"7vehhfjteu.fsf@alter.siamese.dyndns.org","threadId":"32678","inReplyTo":"20130120233422.GB3474@elie.Belkin","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-21T00:01:29Z","receivedAt":"2013-01-21T00:01:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Eric S. Raymond wrote:\n>\n>> You get to integrate this. I think the transition strategy Junio\n>> has chosen is seriously mistaken, leading to unnecessary grief for users\n>> who will be fooled into thinking it's OK to still use cvsps-2.x.\n>\n> So our choices are:\n>\n> a. support current users, offend ESR, don't benefit from ESR\n> improvements\n>\n> b. give up on current users, please ESR, benefit from ESR\n> improvements\n>\n> c. some option yet undiscovered\n>\n> In that case, (c) sounds like our best bet. Do I understand\n> correctly?\n>\n> Sigh,\n> Jonathan\n\nIsn't (c) is to just build on cvsimport-2 and cvsimport-3 combo?\n\nIf Eric does not want to get involved in cvsimport-2 (and cvsps2),\nthat is perfectly fine. We have the beginning of cvsimport-3 code\nthat was released with Sign-off, and as long as cvsps3 produces a\n\"more corrrect\" output stream (either traditional cvsps2 style or as\na fast-import stream) than cvsps2 conversion describes, cvsimport-3\ncan get the full benefit of his work, no?\n\nI do not think that Eric will be the only person who understands\ncvsps3 output who can fix bugs that may potentially still exist in\ncvsimport-3 code [*1*].\n\nWe live in real world, and distro inertia makes it likely that a new\nversion of git that does not work for people who have been happy\nwith cvsps2 will get resistance from them, when they do not trust\nthe 0.x releases of a new piece of software \"cvsps3\" that happens to\nhave a name similar to what they have been shipping, i.e. \"cvsps2\".\nShipping such a crippled Git will not be an effective way to promote\nadoption of \"cvsps3\".\n\n[Footnote]\n\n*1* This of course assumes Eric's two major claims are true, that\nis, (1) cvsimport-3 is already mature and better than cvsimport-2,\nand (2) the code is so simple that it does not even need its own\ntests as long as the front-end conversion that happens at the cvsps3\nend is tested well. Choosing b. will have to assume them to be true\nanyway, so I do not think it is a big loss to rely on the same\nassumptions and choose b. from our point of view.\n"},{"id":"207346","messageId":"7va9s3jt78.fsf@alter.siamese.dyndns.org","threadId":"32678","inReplyTo":"7vehhfjteu.fsf@alter.siamese.dyndns.org","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-21T00:06:03Z","receivedAt":"2013-01-21T00:06:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> ..., so I do not think it is a big loss to rely on the same\n> assumptions and choose b. from our point of view.\n\nOf course the last sentence is a typo: \"choose c.\" is what I meant.\n"},{"id":"207348","messageId":"20130121010643.GA25437@thyrsus.com","threadId":"32678","inReplyTo":"20130120234205.GC3474@elie.Belkin","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2013-01-21T01:06:43Z","receivedAt":"2013-01-21T01:06:43Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Jonathan Nieder :\n> Junio proposed a transition strategy, but I don't think it's fair to\n> say he has chosen it without discussion or is imposing it on you.\n\nI have said everything I could about the bad effects of encouraging\npeople to continue to use cvsps-2.x, it didn't budge Junio an\ninch, and I'm tired of fighting about it. Quibbling about the \nsemantics of 'impose' will neither change these facts nor make\nme any less frustrated with the outcome.\n\nI will continue to do what I can to make cvsps-3.x and cvs-fast-export as\nbug-free as possible, given the innate perverseness of CVS. They\nwon't be perfect; they will be *better*.\n-- \n\t\tEric S. Raymond\n"},{"id":"207366","messageId":"20130121064203.GA3265@elie.Belkin","threadId":"32678","inReplyTo":"20130121010643.GA25437@thyrsus.com","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-21T06:42:03Z","receivedAt":"2013-01-21T06:42:03Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Eric S. Raymond wrote:\n\n> I have said everything I could about the bad effects of encouraging\n> people to continue to use cvsps-2.x, it didn't budge Junio an\n> inch, and I'm tired of fighting about it.\n\nWhat I think you misunderstood is that Junio is not the person you\nwould have needed to convince. (Nor is it me.)\n\n[...]\n> I will continue to do what I can to make cvsps-3.x and cvs-fast-export as\n> bug-free as possible, given the innate perverseness of CVS.\n\nThat's all anyone could hope for. :) Thanks.\n\nCiao,\nJonathan\n"},{"id":"207367","messageId":"7vr4lfgfkm.fsf@alter.siamese.dyndns.org","threadId":"32678","inReplyTo":"20130121010643.GA25437@thyrsus.com","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-21T07:28:41Z","receivedAt":"2013-01-21T07:28:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Eric S. Raymond\" writes:\n\n> Jonathan Nieder :\n>> Junio proposed a transition strategy, but I don't think it's fair to\n>> say he has chosen it without discussion or is imposing it on you.\n>\n> I have said everything I could about the bad effects of encouraging\n> people to continue to use cvsps-2.x, it didn't budge Junio an\n> inch, and I'm tired of fighting about it. Quibbling about the \n> semantics of 'impose' will neither change these facts nor make\n> me any less frustrated with the outcome.\n\nI am not quite sure if I follow you.\n\nThe primary thing I am aiming for is to rob an excuse from people\nand from their distros to block newer Git and cvsps3. I've already\ncited a few URLs where we can see cvsps3 is blocked with an excuse\n\"it does not work with Git yet\".\n\nIf we ship new version of Git that only works with cvsps3, we will\nend up giving an excuse \"this version of Git no longer works with\ncvsps2\" for distro packagers whose cvsps distro maintainer is slower\nthan others to pick up cvsps3 for whatever reason.\n\nYou may care deeply about CVS conversion part of the system, but you\nneed to realize that majority of Git users do not care a whit about\ncvsimport. I do not want to give those distros that ship stale cvsps\nan excuse to pin their users at an old version of Git.\n\nBy shipping both cvsimport-2 and cvsimport-3, we will rob from these\ndistros the excuse to block shipping the version of Git that does\nsupport cvsps3 output. They can choose to update cvsps to 3.x and\ndisable cvsimport-2 altogether at the build time, or if their cvsps\ndistro maintainer is slow, they can ship both cvsimport-2 and -3 and\nlet the user install cvsps 3.x under their $HOME if they want.\n\nIf you want to abandon cvsps2 users, that is perfectly fine by me.\nAs long as cvsps3 and cvsimport-3 combo works, Git before this\nseries will have a _working_ cvsimport as far as I am concerned.\n\nIn other words, I am fine to add a paragraph at the top of the\nRelease Notes saying that\n\n (1) cvsps2 is no longer maintained;\n\n (2) using cvsps3 is the future direction for the users; and\n\n (3) if their distro is slow to adopt cvsps3, however, cvsimport can\n still be used with cvsps2, but bugs in it or cvsps2 are not\n expected to be fixed.\n\nto nudge distros to adopt cvsps3.\n\n> I will continue to do what I can to make cvsps-3.x and cvs-fast-export as\n> bug-free as possible, given the innate perverseness of CVS. They\n> won't be perfect; they will be *better*.\n\nYes, that is what we want.\n"},{"id":"207368","messageId":"7va9s3gf9k.fsf@alter.siamese.dyndns.org","threadId":"32678","inReplyTo":"7vr4lfgfkm.fsf@alter.siamese.dyndns.org","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-21T07:35:19Z","receivedAt":"2013-01-21T07:35:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> If you want to abandon cvsps2 users, that is perfectly fine by me.\n> As long as cvsps3 and cvsimport-3 combo works, Git before this\n> series will have a _working_ cvsimport as far as I am concerned.\n\nThe above obviously is \"Git _after_ this series\".\n\nGit before this series that only has cvsps2 support may be broken\nand Git after this series, when used with cvsps2, may be broken, but\nis broken the same way as before, so it is not a net loss.\n\nThe users of distros that are slow to update cvsps can still use\ncvsimport-3 with cvsps3 that is manually installed, and the users of\ndistros that ship cvsps3 will use cvsimport-3 and they can migrate\naway from cvsps2's breakage.\n"},{"id":"207387","messageId":"20130121093658.GD7498@serenity.lan","threadId":"32678","inReplyTo":"20130120232008.GA25001@thyrsus.com","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-01-21T09:36:58Z","receivedAt":"2013-01-21T09:36:58Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Sun, Jan 20, 2013 at 06:20:08PM -0500, Eric S. Raymond wrote:\n> John Keeping :\n>> I don't think there is any way to solve this without giving cvsps more\n>> information, probably the last commit time for all git branches, but\n>> perhaps I'm missing a fast-import feature that can help solve this\n>> problem.\n> \n> Yes, you are. The magic incantation is\n> \n> from refs/heads/^0\n> \n> I've just pushed a cvsps-3.9 with an -i option that generates these at\n> each branch root. Combine it with -d and you get incremental\n> fast-export.\n\nI don't think this is enough. I made a very similar change here for\ntesting (conditional on relative_date_start instead of a new flag) and I\nneeded this as well in order to prevent empty duplicate commits being\nadded:\n\n-- >8 --\n\ndiff --git a/cvsps.c b/cvsps.c\nindex fb6a3ad..5771462 100644\n--- a/cvsps.c\n+++ b/cvsps.c\n@@ -1560,7 +1560,7 @@ static bool visible(PatchSet * ps)\n ok:\n //fprintf(stderr, \"Time check: %zd %zd %zd\\n\", restrict_date_start, restrict_date_end, ps->date);\n if (restrict_date_start > 0 &&\n-\t(ps->date < restrict_date_start ||\n+\t(ps->date <= restrict_date_start ||\n \t (restrict_date_end > 0 && ps->date > restrict_date_end)))\n \treturn false;\n \n-- 8< --\n\n\nBut this is nothing more than a sticking plaster that happens to do\nenough in this particular case - if the Git repository happened to be on\na different branch, the start date would be wrong and too many or too\nfew commits could be output. Git doesn't detect that they commits are\nidentical to some that we already have because we're explicitly telling\nit to make a new commit with the specified parent.\n\nYou can easily see the breakage by running the tests in the Git tree,\nwhere the CVS revision map tests fail because they end up with duplicate\nversions.\n\nYou'll need my cvsimport-3 branch to see these failures as it adds the\n\"git config\" support that the tests rely on:\n\n git://github.com/johnkeeping/git.git cvsimport-3\n\n\nJohn\n"},{"id":"207389","messageId":"20130121112853.GA31693@thyrsus.com","threadId":"32678","inReplyTo":"20130121093658.GD7498@serenity.lan","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2013-01-21T11:28:53Z","receivedAt":"2013-01-21T11:28:53Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"John Keeping :\n> But this is nothing more than a sticking plaster that happens to do\n> enough in this particular case\n\nI'm beginning to think that's the best outcome we ever get in this\nproblem domain...\n\n> - if the Git repository happened to be on\n> a different branch, the start date would be wrong and too many or too\n> few commits could be output. Git doesn't detect that they commits are\n> identical to some that we already have because we're explicitly telling\n> it to make a new commit with the specified parent.\n\nThen I don't understand the actual failure case. Either that or you\ndon't understand the effect of -i. Have you actually experimented with\nit? The reason I suspect you don't understand the feature is that it\nshouldn't make any difference to the way -i works which repository branch is\nactive at the time of the second import.\n\nHere is how I model what is going on:\n\n1. We make commits to multiple branches of a CVS repo up to some given time T.\n\n2. We import it, ending up with a collection of git branches all of which \n have tip commits dated T or earlier. And *every* commit dated T or earlier\n gets copied over.\n\n3. We make more commits to the same set of branches in CVS.\n\n4. We now run cvsps -d T on the repo. This generates an incremental\n fast-import stream describing all CVS commits *newer* than T (see\n the cvsps manual page).\n\n5. That stream should consist of a set of disconnected branches, each\n (because of -i) beginning with a root commit containing \"from\n refs/heads/foo^0\" which says to parent the commit on the tip of\n branch foo, whatever that happens to be. (I don't have to guess\n about this, I tested the feature before shipping.)\n\n6. Now, when git fast-import interprets that stream in the context of\n the repository produced in step 2, for each branch in the\n incremental dump the branch root commit is parented on the tip\n commit of the same branch in the repo.\n \nAt step 6, it shouldn't matter at all which branch is active, because\nwhere an incremental branch root gets attached has nothing to do with\nwhich branch is active. \n\nIt is sufficient to avoid duplicate commits that cvsps -d 0 -d T and\ncvsps -d T run on the same CVS repo operate on *disjoint sets* of CVS\nfile commits. I can see this technique possibly getting confused if T\nfalls in the middle of a changeset where the CVS timestamps for the\nfile commits are out of order. But that's the same case that will\nfail if we're importing at file-commit granularity, so there's no new\nbug here.\n\nCan you explain at what step my logic is incorrect?\n-- \n\t\tEric S. Raymond\n"},{"id":"207391","messageId":"20130121120010.GE7498@serenity.lan","threadId":"32678","inReplyTo":"20130121112853.GA31693@thyrsus.com","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-01-21T12:00:10Z","receivedAt":"2013-01-21T12:00:10Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, Jan 21, 2013 at 06:28:53AM -0500, Eric S. Raymond wrote:\n> John Keeping :\n>> But this is nothing more than a sticking plaster that happens to do\n>> enough in this particular case\n> \n> I'm beginning to think that's the best outcome we ever get in this\n> problem domain...\n\nI don't think we can ever get a perfect outcome, but it should be\npossible to do a little bit better without too much effort.\n\n>> - if the Git repository happened to be on\n>> a different branch, the start date would be wrong and too many or too\n>> few commits could be output. Git doesn't detect that they commits are\n>> identical to some that we already have because we're explicitly telling\n>> it to make a new commit with the specified parent.\n> \n> Then I don't understand the actual failure case. Either that or you\n> don't understand the effect of -i. Have you actually experimented with\n> it? The reason I suspect you don't understand the feature is that it\n> shouldn't make any difference to the way -i works which repository branch is\n> active at the time of the second import.\n> \n> Here is how I model what is going on:\n> \n> 1. We make commits to multiple branches of a CVS repo up to some given time T.\n> \n> 2. We import it, ending up with a collection of git branches all of which \n> have tip commits dated T or earlier. And *every* commit dated T or earlier\n> gets copied over.\n>\n> 3. We make more commits to the same set of branches in CVS.\n> \n> 4. We now run cvsps -d T on the repo. This generates an incremental\n> fast-import stream describing all CVS commits *newer* than T (see\n> the cvsps manual page).\n\nThis is the problem step. There are two scenarios that have problems:\n\n1. If I create a new development branch in my Git repository and commit\n something to it then git-cvsimport-3 will pass a time to cvsps that\n is newer than the actual time of the last import, so T is wrong.\n\n It may be possible to fix this case purely in git-cvsimport-3.\n\n2. If the branch I have checked out is not the newest CVS branch, then\n git-cvsimport-3 will pass a value of T that is before the time of the\n last import. This case is more subtle but it results in unwanted\n duplicate commits since git-fast-import will just do what it's told\n and create the new commits.\n\n So if we have the following commits:\n\n commit1 at time 1\n commit2 at time 2\n commit3 at time 3\n\n and I call \"cvsps -d 2 -i\" I end up with the series:\n\n commit1 at time 1\n commit2 at time 2\n commit3 at time 3\n commit2 at time 2 - effectively reverting the previous commit\n commit3 at time 3 - a duplicate\n ... and potentially genuinely new commits\n\n This is demonstrated by running the Git test t9650.\n\nI also disagree that cvsps outputs commits *newer* than T since it will\nalso output commits *at* T, which is what I changed with the patch in my\nprevious message. This fixes the duplicate commit2 in the series above,\nbut not the duplicate commit3.\n\n> 5. That stream should consist of a set of disconnected branches, each\n> (because of -i) beginning with a root commit containing \"from\n> refs/heads/foo^0\" which says to parent the commit on the tip of\n> branch foo, whatever that happens to be. (I don't have to guess\n> about this, I tested the feature before shipping.)\n> \n> 6. Now, when git fast-import interprets that stream in the context of\n> the repository produced in step 2, for each branch in the\n> incremental dump the branch root commit is parented on the tip\n> commit of the same branch in the repo.\n> \n> At step 6, it shouldn't matter at all which branch is active, because\n> where an incremental branch root gets attached has nothing to do with\n> which branch is active. \n> \n> It is sufficient to avoid duplicate commits that cvsps -d 0 -d T and\n> cvsps -d T run on the same CVS repo operate on *disjoint sets* of CVS\n> file commits. I can see this technique possibly getting confused if T\n> falls in the middle of a changeset where the CVS timestamps for the\n> file commits are out of order. But that's the same case that will\n> fail if we're importing at file-commit granularity, so there's no new\n> bug here.\n> \n> Can you explain at what step my logic is incorrect?\n\nYour logic is correct - for cvsps - the problem is where T comes from.\n\nPerhaps it is simplest to just save a CVS_LAST_IMPORT_TIME file in\n$GIT_DIR and not worry about it any more.\n\n\nJohn\n"},{"id":"207393","messageId":"20130121124340.GA32219@thyrsus.com","threadId":"32678","inReplyTo":"20130121120010.GE7498@serenity.lan","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2013-01-21T12:43:40Z","receivedAt":"2013-01-21T12:43:40Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"John Keeping :\n> I also disagree that cvsps outputs commits *newer* than T since it will\n> also output commits *at* T, which is what I changed with the patch in my\n> previous message.\n\nAh. OK, that is yet another bug inherited from 2.x - the code doesn't\nmatch the documented (and correct) behavior. Please send me a patch\nagainst the cvsps repo, I'll merge it.\n\n> Perhaps it is simplest to just save a CVS_LAST_IMPORT_TIME file in\n> $GIT_DIR and not worry about it any more.\n\nYes, I think you're right. Trying to carry that information in-band would\nprobably doom us to all sorts of bug-prone complications.\n\nThanks for the good analysis. I wish everybody I had to chase bugs with\ncould explain them with such clarity and concision.\n\nSigh. Now I have to figure out if cvsps's behavior can be rescued in Chris\nRorvick's recently-discovered failure case. I'm not optimistic.\n-- \n\t\tEric S. Raymond\n"},{"id":"207396","messageId":"20130121132706.GF7498@serenity.lan","threadId":"32678","inReplyTo":"20130121124340.GA32219@thyrsus.com","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-01-21T13:27:06Z","receivedAt":"2013-01-21T13:27:06Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, Jan 21, 2013 at 07:43:40AM -0500, Eric S. Raymond wrote:\n> John Keeping :\n>> I also disagree that cvsps outputs commits *newer* than T since it will\n>> also output commits *at* T, which is what I changed with the patch in my\n>> previous message.\n> \n> Ah. OK, that is yet another bug inherited from 2.x - the code doesn't\n> match the documented (and correct) behavior. Please send me a patch\n> against the cvsps repo, I'll merge it.\n\nShould now be in your inbox.\n\n> > Perhaps it is simplest to just save a CVS_LAST_IMPORT_TIME file in\n> > $GIT_DIR and not worry about it any more.\n> \n> Yes, I think you're right. Trying to carry that information in-band would\n> probably doom us to all sorts of bug-prone complications.\n\nI think the only way to do it without needing to save local state in the\nGit repository would be to teach cvsps to read a table of refs and times\nfrom its stdin so that we could do something like:\n\n git for-each-ref --format='%(refname)%09%(*authordate:raw)' refs/heads/ |\n cvsps -i --branch-times-from-stdin |\n git fast-import\n\nThen cvsps could create a hash table from this and use that to decide\nwhether a patch set is interesting or not.\n\n\nJohn\n"},{"id":"207399","messageId":"20130121140719.GA1409@thyrsus.com","threadId":"32678","inReplyTo":"20130121132706.GF7498@serenity.lan","subject":"Re: git-cvsimport-3 and incremental imports","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2013-01-21T14:07:19Z","receivedAt":"2013-01-21T14:07:19Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"John Keeping :\n> > Ah. OK, that is yet another bug inherited from 2.x - the code doesn't\n> > match the documented (and correct) behavior. Please send me a patch\n> > against the cvsps repo, I'll merge it.\n> \n> Should now be in your inbox.\n\nReceived, merged, tested, and cvsps-3.10 has shipped.\n \n> I think the only way to do it without needing to save local state in the\n> Git repository would be to teach cvsps to read a table of refs and times\n> from its stdin so that we could do something like:\n> \n> git for-each-ref --format='%(refname)%09%(*authordate:raw)' refs/heads/ |\n> cvsps -i --branch-times-from-stdin |\n> git fast-import\n> \n> Then cvsps could create a hash table from this and use that to decide\n> whether a patch set is interesting or not.\n\nAgreed. I considered implementing something quite this before thinking of\nthe ^0 hack. But an out-of-band timestamp file is much simpler.\n-- \n\t\tEric S. Raymond\n"}]}