{"thread":{"id":"28914","subject":"Git: CVS to Git import","startedAt":"2011-11-11T23:17:33Z","lastAt":"2011-11-14T02:44:03Z","messageCount":4,"participants":["Jvsrvcs","Jakub Narebski","Jonathan Nieder","Matthew Ogilvie"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"179337","messageId":"1321053453892-6987037.post@n2.nabble.com","threadId":"28914","inReplyTo":null,"subject":"Git: CVS to Git import","fromName":"Jvsrvcs","fromEmail":"jvsrvcs@gmail.com","sentAt":"2011-11-11T23:17:33Z","receivedAt":"2011-11-11T23:17:33Z","isPatch":false,"sender":{"key":"jvsrvcs@gmail.com","avatar":null},"body":"Git: CVS to Git import\n\nWe are moving from CVS to Git and want to know if anyone has had any\nexperience there doing this and could share do's / dont's, best practices\nwhen doing the initial import.\n\nAlso are there any known problems/bugs with the cvs to git import with\nregards to CVS history?\n\nRegards,\n\nJ.V.\n\n--\nView this message in context: http://git.661346.n2.nabble.com/Git-CVS-to-Git-import-tp6987037p6987037.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"179338","messageId":"m3obwimdi1.fsf@localhost.localdomain","threadId":"28914","inReplyTo":"1321053453892-6987037.post@n2.nabble.com","subject":"Re: Git: CVS to Git import","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-11-11T23:43:47Z","receivedAt":"2011-11-11T23:43:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jvsrvcs writes:\n\n> Git: CVS to Git import\n> \n> We are moving from CVS to Git and want to know if anyone has had any\n> experience there doing this and could share do's / dont's, best practices\n> when doing the initial import.\n> \n> Also are there any known problems/bugs with the cvs to git import with\n> regards to CVS history?\n\nI think that Eric S Raymond \"DVCS Migration Guide\"\n\n http://www.catb.org/esr/dvcs-migration-guide.html\n\nand reposurgeon tool (to clean up conversion artifacts)\n\n http://www.catb.org/esr/reposurgeon/\n\nmight help.\n\n-- \nJakub Narębski\n"},{"id":"179342","messageId":"20111112002426.GA6602@elie.hsd1.il.comcast.net","threadId":"28914","inReplyTo":"m3obwimdi1.fsf@localhost.localdomain","subject":"Re: Git: CVS to Git import","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-11-12T00:24:26Z","receivedAt":"2011-11-12T00:24:26Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJakub Narebski wrote:\n> Jvsrvcs writes:\n\n>> Git: CVS to Git import\n>> \n>> We are moving from CVS to Git and want to know if anyone has had any\n>> experience there doing this and could share do's / dont's, best practices\n>> when doing the initial import.\n[...]\n> I think that Eric S Raymond \"DVCS Migration Guide\"\n>\n> http://www.catb.org/esr/dvcs-migration-guide.html\n\nThat page says that \"git cvsimport\" tends to be your best bet. But my\nexperience is exactly the opposite --- git-cvsimport can make a lot of\nmistakes, some of them documented in the ISSUES section of its\nmanpage, and it is hard to notice until later.\n\nI've have good experiences using cvs2git from\n (but note that it does not support\nincremental imports).\n\n> and reposurgeon tool (to clean up conversion artifacts)\n>\n> http://www.catb.org/esr/reposurgeon/\n\nLast time I checked, reposurgeon loads the entire history in memory.\nFor projects with a longer history, \"git filter-branch\" might be a\nbetter fit.\n\nBy the way, thanks for writing. If your experience results in some\nideas for improving Documentation/gitcvs-migration.txt page, we'll\nprobably be happy to take them. :)\n\nGood luck,\nJonathan\n"},{"id":"179403","messageId":"20111114024403.GA2905@comcast.net","threadId":"28914","inReplyTo":"1321053453892-6987037.post@n2.nabble.com","subject":"Re: Git: CVS to Git import","fromName":"Matthew Ogilvie","fromEmail":"mmogilvi_git@miniinfo.net","sentAt":"2011-11-14T02:44:03Z","receivedAt":"2011-11-14T02:44:03Z","isPatch":false,"sender":{"key":"mmogilvi_git@miniinfo.net","avatar":null},"body":"On Fri, Nov 11, 2011 at 03:17:33PM -0800, Jvsrvcs wrote:\n> Git: CVS to Git import\n> \n> We are moving from CVS to Git and want to know if anyone has had any\n> experience there doing this and could share do's / dont's, best practices\n> when doing the initial import.\n\nSome ideas:\n\nI wouldn't trust \"git cvsimport\". In my testing, it was actaully fairly\ncommon for the resulting git tags and branches to be inconsistent with the\noriginal CVS tags and branches: checking out a tag from CVS and the same\ntag from GIT, the trees were often different. See the manpage\nfor a list of some of the known issues. \n\nUse cvs2git instead.\n\nWrite up your own script to do the conversion. Iteratively inspect\nthe results, find ways to fix up anything you don't like,\nand re-run the script. Any \"fixups\" you want should be\nscripted, so that you can try different things, examine\nthe result. Then when the actual \"real\" conversion\nhappens, you have a minimal amount of downtime as you your\nalready-tested script runs.\n\nThe exact fixups your script should do depend on your\ncircumstances, but in my case, some of things my script did included:\n\n - First, copy the CVS repository, and work with the copy:\n - Delete some \",v\" files we didn't interested in importing into git for\n various reasons.\n - Tweak some CVS commit timestamps in some files (such as a version\n file), to reduce import odditities. (The most common oddities\n resulted from an old CVS workflow that would often sequence:\n (a) checkout, (b) modify version number file, (c) build, (d) commit\n the new version number file, and (e) tag the sandbox. It was\n was moderately common for other changes (in other files) to\n be committed between (a) and (d), which will either cause\n strange import artifacts or actually break import tools, due to\n the out-of-order timestamps. Tweaking back the timestamp in the\n CVS file typically allows the import tool to avoid the\n oddity. Completely cleaning this up would have been a\n lot of work, so I focused just on just improving recent\n history.) (sed -i ...)\n - Do the bulk of the import work using cvs2git.\n - Graft on appropriate merge history (multiple parents) for\n CVS merges. To save time, I only worried about recent merges.\n - If you have a nice consistent tag naming\n convention, there are ways to do this as part of cvs2git.\n Unfortunately, we didn't.\n - Do not refer to a previous run's commit SHA-1's; they'll\n likely change as things change. Use CVS tags instead.\n - git rev-parse is useful for looking up current references\n to construct graft lines.\n - Use git filter-branch to both make the above grafts permanent,\n and to fix commiter/author username/email.\n - Move imported tags and branches to refs/oldcvstags/*\n and refs/oldcvsbranches/*, to bury a lot of the noise\n (automatic build tags, tags applied as part of doing a\n merge, etc) to where a normal \"git clone\" will not grab\n them, but they can still be fetched manually if necessary.\n - Copy/rename a few recent release tags and branches to\n normal refs/tags/* and refs/heads/*, when they are actually\n useful. (git pack-refs and sed)\n - Something like: sleep 5 ; git gc --aggressive --prune='1 second ago'\n\n--\nMatthew Ogilvie [mmogilvi_git@miniinfo.net]\n"}]}