{"thread":{"id":"33820","subject":"Fwd: git cvsimport implications","startedAt":"2013-05-14T22:09:09Z","lastAt":"2013-05-18T05:52:03Z","messageCount":13,"participants":["Eugene Sajine","Junio C Hamano","Michael Haggerty","John Keeping","Martin Langhoff","Andreas Krey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"217383","messageId":"CAPZPVFZLDwLNazvBh5n=Jg_=CZUNz3yTme4JW2NutPgjPzwtLg@mail.gmail.com","threadId":"33820","inReplyTo":"CAPZPVFYFL6OS2HWbF0BKNKtNsZ6CfpWmKCypGxeTs7W8-76q8Q@mail.gmail.com","subject":"Fwd: git cvsimport implications","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2013-05-14T22:09:09Z","receivedAt":"2013-05-14T22:09:09Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"Hi,\n\nWe are using git cvsimport heavily but mostly the projects are not\nusing branches that much. We are also migrating our repos only once,\nso there is  no commits to CVS repo and no incremental imports allowed\nafter the migration. we have migrated more than a thousand projects\nalready.\n\nwe use the simplest way (from the CVS checkout folder)\n\n$ git cvsimport -C /path/to/new/git/repo\n\nJust recently it was brought to my attention that we can have problems\nwith that tool. So my question is if anybody could advise which\nscenarios are safe to use this tool for, and what is not recommended?\n\nWhat if there are a lot of branches in the CVS repo? Is it guaranteed\nto be broken after import?\n\nDo i understand correctly that it might put some files into a branch,\nthat were not originally in this branch in CVS? In which cases it\nmight happen (i'm sorry i didn't quite get the \"issues\" in the man\npages for cvsimport)?\n\nThanks,\nEugene\n"},{"id":"217388","messageId":"7vfvxpfbli.fsf@alter.siamese.dyndns.org","threadId":"33820","inReplyTo":"CAPZPVFZLDwLNazvBh5n=Jg_=CZUNz3yTme4JW2NutPgjPzwtLg@mail.gmail.com","subject":"Re: Fwd: git cvsimport implications","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-14T22:19:53Z","receivedAt":"2013-05-14T22:19:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eugene Sajine <euguess@gmail.com> writes:\n\n> What if there are a lot of branches in the CVS repo? Is it guaranteed\n> to be broken after import?\n\nEven though CVS repository can record branches in individual ,v\nfiles, reconstructing per branch history and where the branch\nhappened in each \"changeset\" cannot be determined with any\ncertainty.  The best you can get is a heuristic result.\n\nI do not think anybody can give such a guarantee.  The best you can\ndo is to convert it and validate if the result matches what you\nthink has happened in the CVS history.\n"},{"id":"217411","messageId":"51932A1A.4050606@alum.mit.edu","threadId":"33820","inReplyTo":"7vfvxpfbli.fsf@alter.siamese.dyndns.org","subject":"Re: Fwd: git cvsimport implications","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-05-15T06:24:26Z","receivedAt":"2013-05-15T06:24:26Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 05/15/2013 12:19 AM, Junio C Hamano wrote:\n> Eugene Sajine <euguess@gmail.com> writes:\n> \n>> What if there are a lot of branches in the CVS repo? Is it guaranteed\n>> to be broken after import?\n> \n> Even though CVS repository can record branches in individual ,v\n> files, reconstructing per branch history and where the branch\n> happened in each \"changeset\" cannot be determined with any\n> certainty.  The best you can get is a heuristic result.\n> \n> I do not think anybody can give such a guarantee.  The best you can\n> do is to convert it and validate if the result matches what you\n> think has happened in the CVS history.\n\nJunio, you are correct that there is no 100% reliable way of inferring\nthe changesets that were made in CVS.  CVS doesn't record which file\nrevisions were committed at the same time, unambiguous branch points,\netc.  The best a tool can do is use heuristics.\n\nBut it *is* possible for a conversion tool to make some more elementary\nguarantees regarding aspects of the history that are recorded\nunambiguously in CVS, for example:\n\n* That if you check the tip of same branch out of CVS and out of Git,\nyou get the same contents.\n\n* That CVS file revisions are committed to Git in the correct order\nrelative to each other; e.g., that the changes made in CVS revision\n1.4.2.2 in a particular file precede those made in revision 1.4.2.3 of\nthe same file.\n\ngit-cvsimport fails to ensure even this minimal level of correctness.\nSuch errors are demonstrated in its own test suite.\n\ncvs2git, on the other hand, gets the basics 100% correct (if you find a\ndiscrepancy, please file a bug!), in addition to having great heuristics\nfor inferring the details of the history.\n\nThere is no reason ever to use git-cvsimport for one-time conversions\nfrom CVS to Git.  The only reason ever to use it is if you absolutely\nrequire an incremental bridge between CVS and Git, and even then please\nuse it with great caution.\n\nMichael\nthe cvs2svn/cvs2git maintainer\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"217464","messageId":"CAPZPVFZTZFQrCF3gcwcff5LFm9MHhZm-DauLvfzCYrMTw4nQfA@mail.gmail.com","threadId":"33820","inReplyTo":"51932A1A.4050606@alum.mit.edu","subject":"Re: Fwd: git cvsimport implications","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2013-05-15T18:03:13Z","receivedAt":"2013-05-15T18:03:13Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"Hi\n\nMy primary goal was to understand better what are the real problems\nthat we might have with the way we use git cvsimport, so I was not\nasking about the guarantee of the cvsimport to import things\ncorrectly, but if there is a guarantee the import will result in\ncompletely broken history. IF there is a situation when cvsimport can\ndo things right and when it definitely going to fail?\n\nAnyway, thanks a lot for the info. I do know that cvs2git is an option.\n\nIf the cvsimport is that broken - is there any plan to fix it?\n\nThanks,\nEugene\n\nOn Wed, May 15, 2013 at 2:24 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> On 05/15/2013 12:19 AM, Junio C Hamano wrote:\n>> Eugene Sajine <euguess@gmail.com> writes:\n>>\n>>> What if there are a lot of branches in the CVS repo? Is it guaranteed\n>>> to be broken after import?\n>>\n>> Even though CVS repository can record branches in individual ,v\n>> files, reconstructing per branch history and where the branch\n>> happened in each \"changeset\" cannot be determined with any\n>> certainty.  The best you can get is a heuristic result.\n>>\n>> I do not think anybody can give such a guarantee.  The best you can\n>> do is to convert it and validate if the result matches what you\n>> think has happened in the CVS history.\n>\n> Junio, you are correct that there is no 100% reliable way of inferring\n> the changesets that were made in CVS.  CVS doesn't record which file\n> revisions were committed at the same time, unambiguous branch points,\n> etc.  The best a tool can do is use heuristics.\n>\n> But it *is* possible for a conversion tool to make some more elementary\n> guarantees regarding aspects of the history that are recorded\n> unambiguously in CVS, for example:\n>\n> * That if you check the tip of same branch out of CVS and out of Git,\n> you get the same contents.\n>\n> * That CVS file revisions are committed to Git in the correct order\n> relative to each other; e.g., that the changes made in CVS revision\n> 1.4.2.2 in a particular file precede those made in revision 1.4.2.3 of\n> the same file.\n>\n> git-cvsimport fails to ensure even this minimal level of correctness.\n> Such errors are demonstrated in its own test suite.\n>\n> cvs2git, on the other hand, gets the basics 100% correct (if you find a\n> discrepancy, please file a bug!), in addition to having great heuristics\n> for inferring the details of the history.\n>\n> There is no reason ever to use git-cvsimport for one-time conversions\n> from CVS to Git.  The only reason ever to use it is if you absolutely\n> require an incremental bridge between CVS and Git, and even then please\n> use it with great caution.\n>\n> Michael\n> the cvs2svn/cvs2git maintainer\n>\n> --\n> Michael Haggerty\n> mhagger@alum.mit.edu\n> http://softwareswirl.blogspot.com/\n"},{"id":"217686","messageId":"5195F3EB.8000308@alum.mit.edu","threadId":"33820","inReplyTo":"CAPZPVFZTZFQrCF3gcwcff5LFm9MHhZm-DauLvfzCYrMTw4nQfA@mail.gmail.com","subject":"Re: Fwd: git cvsimport implications","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-05-17T09:10:03Z","receivedAt":"2013-05-17T09:10:03Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 05/15/2013 08:03 PM, Eugene Sajine wrote:\n> My primary goal was to understand better what are the real problems\n> that we might have with the way we use git cvsimport, so I was not\n> asking about the guarantee of the cvsimport to import things\n> correctly, but if there is a guarantee the import will result in\n> completely broken history.\n\nSo what are you going to do, use cvsimport whenever you cannot *prove*\nthat it is wrong?  You sure have low standards for your software.\n\nThe only *useful* guarantee is that software is *correct* under defined\ncircumstances.  I don't think anybody has gone to the trouble to figure\nout when that claim can be made for cvsimport.\n\n> If the cvsimport is that broken - is there any plan to fix it?\n\nFor one-time imports, the fix is to use a tool that is not broken, like\ncvs2git.\n\nAlternatively, Eric Raymond claims to have developed a new version of\ncvsps that is not quite as broken as the old version.  Presumably\ncvsimport would be not quite as broken if used with the new cvsps.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"217703","messageId":"20130517092157.GA2299@serenity.lan","threadId":"33820","inReplyTo":"5195F3EB.8000308@alum.mit.edu","subject":"Re: Fwd: git cvsimport implications","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-17T09:21:57Z","receivedAt":"2013-05-17T09:21:57Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Fri, May 17, 2013 at 11:10:03AM +0200, Michael Haggerty wrote:\n> On 05/15/2013 08:03 PM, Eugene Sajine wrote:\n> > My primary goal was to understand better what are the real problems\n> > that we might have with the way we use git cvsimport, so I was not\n> > asking about the guarantee of the cvsimport to import things\n> > correctly, but if there is a guarantee the import will result in\n> > completely broken history.\n> \n> So what are you going to do, use cvsimport whenever you cannot *prove*\n> that it is wrong?  You sure have low standards for your software.\n> \n> The only *useful* guarantee is that software is *correct* under defined\n> circumstances.  I don't think anybody has gone to the trouble to figure\n> out when that claim can be made for cvsimport.\n> \n> > If the cvsimport is that broken - is there any plan to fix it?\n> \n> For one-time imports, the fix is to use a tool that is not broken, like\n> cvs2git.\n> \n> Alternatively, Eric Raymond claims to have developed a new version of\n> cvsps that is not quite as broken as the old version.  Presumably\n> cvsimport would be not quite as broken if used with the new cvsps.\n\ncvsimport doesn't work with the cvsps-3 - we decided to stick with the\nversion we have (using cvsps-2) because that is the only option that\nsupports incremental import; those using if for that are used to its\ndeficiencies and there is no plan to improve it.  The manpage notes that\nit uses a deprecated version of cvsps and recommends alternatives for\none-shot imports.\n\nThere is a version of git-cvsimport script in the cvsps-3 repository\nthat works with it, but it does not support incremental import in the\nsame was as git.git's git-cvsimport so it will not replace the version\nin git.git.\n"},{"id":"217706","messageId":"CACPiFCLqtSy_=1yw6mGWFhNOi=M1rrPNbD6=qpo4FOO_QywCgg@mail.gmail.com","threadId":"33820","inReplyTo":"5195F3EB.8000308@alum.mit.edu","subject":"Re: Fwd: git cvsimport implications","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2013-05-17T11:50:42Z","receivedAt":"2013-05-17T11:50:42Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Fri, May 17, 2013 at 5:10 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> For one-time imports, the fix is to use a tool that is not broken, like\n> cvs2git.\n\nAs one of the earlier maintainers of cvsimport, I do believe that\ncvs2git is less broken, for one-shot imports, than cvsimport. Users\nlooking for a one-shot import should not use cvsimport as there are\nbetter options there. Myself, I have used parsecvs (long ago, so\nperhaps it isn't the best of the crop nowadays).\n\nTBH, I am puzzled and amused at all the chest-thumping about cvs\nimporters. Yeah, yours is a bit better or saner, but we all wade in\nthe muddle of essentially broken data. So \"is not broken\" is rather\nmisleading when talking to end users. It carries so many caveats about\nwhether it'll work on the users' particular repo that it is not a\ngenerally truthful statement.\n\nI am very glad to hear it is better than cvsimport, and even more glad\nto hear its limitations are better understood and documented. It has\nhad a testsuite for the longest of times!\n\nAnd very likely has the best chance of success across the available\nimporters :-)\n\nOh, and why is cvsimport so vague? Because it is just driven by cvsps.\nIt creates a repo based on what cvsps understands from the CVS data.\n\nAt the time, I looked into trying to use cvs2svn (precursor to\ncvs2git) as the \"CVS read\" side of cvsimport, but it did not support\nincremental imports at all, and it took forever to run.\n\nIt was a time when git was new and people were dipping their toes in\nthe pool, and some developers were pining to use git on projects that\nused CVS (like we use git-svn now). Incremental imports were a must.\n\nOne of the nice features of cvsimport is that it can do incrementals\non a repo imported with another tool. That earns it a place under the\nsun. If it didn't have that, I'd be voting for removal (after a review\nthat the replacement *is* actually better ;-) across a number of test\nrepos).\n\ncheers,\n\n\n\nm\n--\n martin.langhoff@gmail.com\n -  ask interesting questions\n - don't get distracted with shiny stuff  - working code first\n ~ http://docs.moodle.org/en/User:Martin_Langhoff\n"},{"id":"217712","messageId":"51962D52.7070200@alum.mit.edu","threadId":"33820","inReplyTo":"CACPiFCLqtSy_=1yw6mGWFhNOi=M1rrPNbD6=qpo4FOO_QywCgg@mail.gmail.com","subject":"Re: Fwd: git cvsimport implications","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-05-17T13:14:58Z","receivedAt":"2013-05-17T13:14:58Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 05/17/2013 01:50 PM, Martin Langhoff wrote:\n> On Fri, May 17, 2013 at 5:10 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n>> For one-time imports, the fix is to use a tool that is not broken, like\n>> cvs2git.\n> \n> As one of the earlier maintainers of cvsimport, I do believe that\n> cvs2git is less broken, for one-shot imports, than cvsimport. Users\n> looking for a one-shot import should not use cvsimport as there are\n> better options there. Myself, I have used parsecvs (long ago, so\n> perhaps it isn't the best of the crop nowadays).\n> \n> TBH, I am puzzled and amused at all the chest-thumping about cvs\n> importers. Yeah, yours is a bit better or saner, but we all wade in\n> the muddle of essentially broken data. So \"is not broken\" is rather\n> misleading when talking to end users. It carries so many caveats about\n> whether it'll work on the users' particular repo that it is not a\n> generally truthful statement.\n\nI disagree.  I use the following definition of \"correct\":\n\n    The Git history output by an importer must not contradict the\n    history that is recorded in CVS.\n\nWe both know that the CVS history omits important data, and that the\nhistory is mutable, etc.  So there are lots of hypothetical histories\nthat do not contradict CVS.  But some things are recorded unambiguously\nin the CVS history, like\n\n* The contents at any tag or the tip of any branch (i.e., what is in the\nworking tree when you check it out).\n\n* The order of modifications to a single file on a single branch and the\nfile contents after each of those revisions.\n\n* Who committed a particular change, and approximately when (modulo\nclock skew).\n\nIf a tool doesn't get these things correct (especially the first!) then\nit should only be used with great caution.  cvsimport can make mistakes\non the first two.  As far as I know, cvs2svn/cvs2git are correct\naccording to this definition.\n\n\nThat being said, I appreciate that cvsimport can do incremental imports.\n cvs2git doesn't even attempt it.  I've thought about what it would take\nto implement correct incremental imports in cvs2svn/cvs2git, and it is\nfar beyond the budget of time that I have for the project.  So I\ndefinitely give props to cvsimport for attempting incremental imports\nand apparently often doing a good enough job that it is useful to people.\n\n> [...]\n> At the time, I looked into trying to use cvs2svn (precursor to\n> cvs2git) as the \"CVS read\" side of cvsimport, but it did not support\n> incremental imports at all, and it took forever to run.\n\ncvs2svn still doesn't support incremental imports, and it still takes a\nlong time to run (though less than before).  cvs2git is considerably\nfaster, partly because of the speed and convenience of using\ngit-fast-import.  But conversion time is much less of an issue for\none-time conversions.\n\n> It was a time when git was new and people were dipping their toes in\n> the pool, and some developers were pining to use git on projects that\n> used CVS (like we use git-svn now). Incremental imports were a must.\n> \n> One of the nice features of cvsimport is that it can do incrementals\n> on a repo imported with another tool. That earns it a place under the\n> sun. If it didn't have that, I'd be voting for removal (after a review\n> that the replacement *is* actually better ;-) across a number of test\n> repos).\n\nIncremental imports are indeed the saving grace of cvsimport and for\nthat reason I don't advocate it's removal.  But I think we should be\nclearer about warning users against using it for one-time imports,\nbecause it can produce output that is *objectively* incorrect in\nimportant ways.\n\nRegarding tests, the failing tests that I added to the cvsimport test\nsuite a few years ago were taken directly from the cvs2svn/cvs2git test\nsuite, where they pass :-)\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"217714","messageId":"20130517133457.GA11496@inner.h.apk.li","threadId":"33820","inReplyTo":"51962D52.7070200@alum.mit.edu","subject":"Re: Fwd: git cvsimport implications","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2013-05-17T13:34:57Z","receivedAt":"2013-05-17T13:34:57Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Fri, 17 May 2013 15:14:58 +0000, Michael Haggerty wrote:\n...\n> We both know that the CVS history omits important data, and that the\n> history is mutable, etc.  So there are lots of hypothetical histories\n> that do not contradict CVS.  But some things are recorded unambiguously\n> in the CVS history, like\n> \n> * The contents at any tag or the tip of any branch (i.e., what is in the\n> working tree when you check it out).\n\nExcept that the tags/branches may be made in a way that can't\nbe mapped onto any commit/point of history otherwise exported,\nwith branches that are done on parts of the trees first, or\nlikewise tags.\n\n...\n> That being said, I appreciate that cvsimport can do incremental imports.\n>  cvs2git doesn't even attempt it.  I've thought about what it would take\n> to implement correct incremental imports in cvs2svn/cvs2git, and it is\n\nDo these two produce stable output? That is, return the same commits\nfor multiple runs on the same repo?\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds <torvalds@*.org>\nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"217713","messageId":"CACPiFCLLw+m=2u8Dsw8u0cU9xrncZ0DwZ9SwOpONWydzCY2t0Q@mail.gmail.com","threadId":"33820","inReplyTo":"20130517133457.GA11496@inner.h.apk.li","subject":"Re: Fwd: git cvsimport implications","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2013-05-17T13:50:00Z","receivedAt":"2013-05-17T13:50:00Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Fri, May 17, 2013 at 9:34 AM, Andreas Krey <a.krey@gmx.de> wrote:\n> On Fri, 17 May 2013 15:14:58 +0000, Michael Haggerty wrote:\n> ...\n>> We both know that the CVS history omits important data, and that the\n>> history is mutable, etc.  So there are lots of hypothetical histories\n>> that do not contradict CVS.  But some things are recorded unambiguously\n>> in the CVS history, like\n>>\n>> * The contents at any tag or the tip of any branch (i.e., what is in the\n>> working tree when you check it out).\n>\n> Except that the tags/branches may be made in a way that can't\n> be mapped onto any commit/point of history otherwise exported,\n> with branches that are done on parts of the trees first, or\n> likewise tags.\n\nYeah, that's what I remember too.  It is perfectly fine in CVS to add\na tag to a file at a much later date than the rest of the tree. And it\nhappened too (\"oh, I didn't have directory support/some-os checked out\nwhen I tagged the release yesterday! let me check it out and add the\ntag, nevermind that the branch has moved forward in the interim...\").\n\nI would add the long history of \"cvs repository manipulation\". Bad,\nugly stuff, but it happened in every major project I've seen. Mozilla,\nX.org, etc.\n\nTBH I am very glad that Michael cares deeply about the correctness,\nand it leads to a much better tool. No doubt.\n\nWhen discussing it with end users, I do think we have to be honest and\nsay that there's a fair chance that the output will not be perfect...\nbecause what is in CVS is rather imperfect when you look at it closely\n(which users aren't usually doing).\n\ncheers,\n\n\n\nm\n--\n martin.langhoff@gmail.com\n -  ask interesting questions\n - don't get distracted with shiny stuff  - working code first\n ~ http://docs.moodle.org/en/User:Martin_Langhoff\n"},{"id":"217719","messageId":"51964CB8.40903@alum.mit.edu","threadId":"33820","inReplyTo":"20130517133457.GA11496@inner.h.apk.li","subject":"Re: Fwd: git cvsimport implications","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-05-17T15:28:56Z","receivedAt":"2013-05-17T15:28:56Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 05/17/2013 03:34 PM, Andreas Krey wrote:\n> On Fri, 17 May 2013 15:14:58 +0000, Michael Haggerty wrote:\n> ...\n>> We both know that the CVS history omits important data, and that the\n>> history is mutable, etc.  So there are lots of hypothetical histories\n>> that do not contradict CVS.  But some things are recorded unambiguously\n>> in the CVS history, like\n>>\n>> * The contents at any tag or the tip of any branch (i.e., what is in the\n>> working tree when you check it out).\n> \n> Except that the tags/branches may be made in a way that can't\n> be mapped onto any commit/point of history otherwise exported,\n> with branches that are done on parts of the trees first, or\n> likewise tags.\n\nThis is true, but cvs2git nevertheless puts the required content on the\nbranch so that it checks out correctly.  In other words, a \"CVS tag\ncreation\" (which might not have been done a single point in time) is\ndone by cvs2git roughly like this (assume it is from master):\n\n1. Make a list of all versions of all files that have to be in the tag.\n\n2. When one of those file versions has to be overwritten (e.g., because\na later version of that file needs to be added to master), create a Git\ntag-branch containing all of the files that are currently at the correct\nversion for the tag.  (It has to be a Git branch, not a tag, because we\nmight have to change it later.)\n\n3. As other files on master go through the revisions needed for the tag,\ncreate new commits on the tag-branch that add those revisions of those\nfiles to the tag-branch.\n\nAt the end of the process, the tag-branch has the same contents as the\nCVS tag, though it may have had to be created via multiple commits.\n\nCurrently, step 3 creates merge commits from master to the tag-branch.\nThis is sometimes what one would expect, sometimes not--a matter of\ntaste, really, because the CVS history is in this aspect more flexible\nthan what is representable in Git's history model.\n\n> ...\n>> That being said, I appreciate that cvsimport can do incremental imports.\n>>  cvs2git doesn't even attempt it.  I've thought about what it would take\n>> to implement correct incremental imports in cvs2svn/cvs2git, and it is\n> \n> Do these two produce stable output? That is, return the same commits\n> for multiple runs on the same repo?\n\nIt usually produces stable output, but not always.  I've had reports of\nusers using cvs2svn successfully as an \"incremental importer\" by simply\nrunning the full import each time and relying on Git to match up the\noverlapping part of the history simply because the SHA-1s are identical.\n But (1) the later conversions would be just as slow as the first, (2)\nsome of the heuristic decisions for grouping CVS file changes into Git\nchangesets can be affected by later commits, and (3) CVS history is\nmutable; if the CVS history is changed retroactively in any way then it\nwon't work at all.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"217720","messageId":"CAPZPVFbkcmBH7OPeP83gPnSGodoi_9diAUk-5dtR43dCDRfkwQ@mail.gmail.com","threadId":"33820","inReplyTo":"CAPZPVFZ6HjFYaPOqcrwhCCdGhYUaVEjyDeaL8dcsqy1ghcfWpg@mail.gmail.com","subject":"Fwd: Fwd: git cvsimport implications","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2013-05-17T16:10:03Z","receivedAt":"2013-05-17T16:10:03Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"MIchael, sorry for dup - didn't press reply all for the first one.\n\n>\n> So what are you going to do, use cvsimport whenever you cannot *prove*\n> that it is wrong?  You sure have low standards for your software.\n\n1. You are making assumptions and conclusions that have no grounds.\nI asked for help understanding what are the problems of cvsimport.\nNever i said i'm not willing use cvs2git. Never i said I'm happy to have\nproblems in my git repos. So, this \"low standard\" punch was... not necessary.\n\n2. I started to use cvsimport because it was the tool *provided with\ngit* about three years ago.\nBy that time i didn't find any better and simpler tool to use and\nthose implications were uknown for me,\nthey were brought up to my attention just recently.\nCVS is not good for branches, so most of our projects didn't have any\ncvs branches.\nSo for majority of those it seems that the cvsimport did it's job just fine.\nNow we are going to try to migrate some projects that are using CVS\nbranches heavily.\nThat concerns me, so i'm looking for better tool.\n\n3. Is there a way to have the whole plumbing with the\nblobfiles and dumpfiles and consequent git fast-import wrapped into\nnice command like:\n\ngit cvsimport -C path/to/my/new/shiny/gitrepo\n\nOr are there any particular reasons why end user must deal with blob\nand dump files and do fast-import afterwards?\n\nThanks,\nEugene\n"},{"id":"217794","messageId":"51971703.5070700@alum.mit.edu","threadId":"33820","inReplyTo":"CAPZPVFbkcmBH7OPeP83gPnSGodoi_9diAUk-5dtR43dCDRfkwQ@mail.gmail.com","subject":"Re: Fwd: Fwd: git cvsimport implications","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-05-18T05:52:03Z","receivedAt":"2013-05-18T05:52:03Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 05/17/2013 06:10 PM, Eugene Sajine wrote:\n> MIchael, sorry for dup - didn't press reply all for the first one.\n> \n>>\n>> So what are you going to do, use cvsimport whenever you cannot *prove*\n>> that it is wrong?  You sure have low standards for your software.\n> \n> 1. You are making assumptions and conclusions that have no grounds.\n> I asked for help understanding what are the problems of cvsimport.\n> Never i said i'm not willing use cvs2git. Never i said I'm happy to have\n> problems in my git repos. So, this \"low standard\" punch was... not necessary.\n\nI didn't mean to be offensive.  I meant it more in the sense of \"you\ndeserve to expect more from your software\".\n\n> 2. I started to use cvsimport because it was the tool *provided with\n> git* about three years ago.\n> By that time i didn't find any better and simpler tool to use and\n> those implications were uknown for me,\n> they were brought up to my attention just recently.\n> CVS is not good for branches, so most of our projects didn't have any\n> cvs branches.\n> So for majority of those it seems that the cvsimport did it's job just fine.\n> Now we are going to try to migrate some projects that are using CVS\n> branches heavily.\n> That concerns me, so i'm looking for better tool.\n\nThe Git test suite (tests t/t960?-*.sh) demonstrates some of the known\nproblems with cvsimport, and those failures are summarized in the\nmanpage for git-cvsimport(1).  Not all of the problems are related to\nbranches and tags.  There might be more problems; I simply documented a\nfew that I found relatively quickly then I stopped looking.\n\n> 3. Is there a way to have the whole plumbing with the\n> blobfiles and dumpfiles and consequent git fast-import wrapped into\n> nice command like:\n> \n> git cvsimport -C path/to/my/new/shiny/gitrepo\n> \n> Or are there any particular reasons why end user must deal with blob\n> and dump files and do fast-import afterwards?\n\nThere are benefits to the split blobfile/dumpfile approach for some\nusers, so I wouldn't want to get rid of that possibility.  But there's\nno reason I wouldn't accept a patch that provides an option to convert\nas you describe.  Alternately, it would take only a few lines of script\nto automate it yourself.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"}]}