{"thread":{"id":"19604","subject":"[RFC] git-cvs script","startedAt":"2009-05-30T13:41:39Z","lastAt":"2009-06-01T10:47:10Z","messageCount":5,"participants":["Nick Woolley","Junio C Hamano","Alex Bennee"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"115084","messageId":"4A213793.3030205@yahoo.co.uk","threadId":"19604","inReplyTo":null,"subject":"[RFC] git-cvs script","fromName":"Nick Woolley","fromEmail":"nickwoolley@yahoo.co.uk","sentAt":"2009-05-30T13:41:39Z","receivedAt":"2009-05-30T13:41:39Z","isPatch":false,"sender":{"key":"nick@noodlefactory.co.uk","avatar":null},"body":"Hi,\n\nI have script which wraps git-cvsimport and git-cvsexport, called \"git-cvs\".\n\nThe main aim of the script is to automate the steps for tracking a CVS\nrepository with the git-cvs* commands.\n\nIt's not currently as sophisticated as git-svn, it's undoubtably flawed and\nisn't foolproof (e.g. exports to CVS of merged git histories can be\nproblematic), but I find it useful, because a lot of the nitty-gritty is done\nfor me.\n\nI'd like to ask:\n\n - Is this at all useful to anyone else in it's current form?\n\n - Is there any prior art I should be aware of? (Presumably most people\n just roll their own scripts, like I have)\n\n - Bearing in mind that it's a work-in progress, are there any suggestions for\n improvement?\n\n\nThe script can be found in its current state here:\n\n http://github.com/wu-lee/git-cvs/\n\n\nThere's no installer, but the script is self-contained and just needs to be on\nthe execution $PATH (as well as git and cvs).\n\nGiven a CVS repository at $CVS_ROOT, tracking a module $CVS_MODULE can be done\nlike this:\n\n # Create a git repo\n git init\n\n # Initialise git-cvs's config file\n echo cvsroot=$CVS_ROOT >.git-cvs\n echo cvsmodule=$CVS_MODULE >>.git-cvs\n\n # First pull gets cvs files using git-cvsimport\n # (optionally you can supply the option\n # --author-file for pass-through\n # to git-cvsimport -A on subsequent invocations)\n git-cvs pull\n\n # hack hack...\n\n # Push the files back into CVS with git-cvsexportcommit\n # (This pushes the commits master..remotes/cvs/cvshead by default,\n # or cvsworking/NAME..remotes/cvs/NAME for each CVS branch NAME)\n git-cvs push\n\n # Pull the changes back into remote/cvs/cvshead and\n # (a messy part I've not found a way round yet) throw away our\n # locally merged commits\n git-cvs pull\n git reset --hard master\n\n # More hacking...\n\n # Repeat push/pull steps as needed\n\n\nSome other points:\n\n - Changes in CVS get pulled back, including multiple branches.\n\n - An author-mapping file can be supplied as for cvs-import -A\n\n - The script creates local CVS working directories\n .git/git-cvs/cvscheckout/NAME, one for each CVS branch NAME.\n\n - Git's master branch tracks CVS's HEAD branch.\n\n - A git branch cvsworking/NAME is created to track each CVS branch NAME.\n\n - Edits in these branches get pushed back to the appropriate CVS branches.\n\n - Verbose subcommand output currently goes into .git/git-cvs/logs.\n\n - Invoking git-cvs with no parameters gets information about the options.\n\n - In an emergency, a list of commit ids can be supplied to git-cvs push.\n\n - Written in Perl, uses only core modules (tested with v5.8.8)\n\n - There is a small test suite in t/, run individually or with \"prove/*.t\"\n\n\n\nThanks,\n\nNick\n"},{"id":"115102","messageId":"7vr5y6xj2a.fsf@alter.siamese.dyndns.org","threadId":"19604","inReplyTo":"4A213793.3030205@yahoo.co.uk","subject":"Re: [RFC] git-cvs script","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-30T23:33:17Z","receivedAt":"2009-05-30T23:33:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nick Woolley writes:\n\n> I have script which wraps git-cvsimport and git-cvsexport, called \"git-cvs\".\n>\n> The main aim of the script is to automate the steps for tracking a CVS\n> repository with the git-cvs* commands.\n\nIf I recall correctly, the above is in line with the original spirit of\nhow git-cvsexportcommit was envisioned to be used by its original authors.\n\nThat is, the import side is more or less satisfactory done in the sense\nthat it deserved a short and sweet command name, but the export side is\nnot as finished as the import side is, and you have to drive it more\nexplicitly by telling what commit to send back to the CVS side. Building\non top of it so the tool keeps track of what needs to be sent, like git-svn\nallows users to do, would be the right thing to do.\n\n> It's not currently as sophisticated as git-svn,...\n> ...\n> - Is this at all useful to anyone else in it's current form?\n\nI have to admit that it won't be to me (because I do not interact with CVS\nmyself) but I don't count ;-)\n"},{"id":"115117","messageId":"b2cdc9f30905310042u592a6f5cv541055194524cce0@mail.gmail.com","threadId":"19604","inReplyTo":"4A213793.3030205@yahoo.co.uk","subject":"Re: [RFC] git-cvs script","fromName":"Alex Bennee","fromEmail":"kernel-hacker@bennee.com","sentAt":"2009-05-31T07:42:10Z","receivedAt":"2009-05-31T07:42:10Z","isPatch":false,"sender":{"key":"kernel-hacker@bennee.com","avatar":null},"body":"2009/5/30 Nick Woolley :\n> Hi,\n>\n> I have script which wraps git-cvsimport and git-cvsexport, called \"git-cvs\".\n>\n> The main aim of the script is to automate the steps for tracking a CVS\n> repository with the git-cvs* commands.\n>\n> It's not currently as sophisticated as git-svn, it's undoubtably flawed and\n> isn't foolproof (e.g. exports to CVS of merged git histories can be\n> problematic), but I find it useful, because a lot of the nitty-gritty is done\n> for me.\n>\n> I'd like to ask:\n>\n>  - Is this at all useful to anyone else in it's current form?\n\nIf this is using the inbuilt cvsps and perl then it will likely choke\non very large CVS repos. For some CVS tree's I've had to resort to a\nhacked up version of parsecvs to get a conversion running.\n\nThe other repo it tends to die on is ones which have been pruned (i.e.\nold branches have been cut off). But people there have made a decision\nto mess with their repo.\n\n>  - Written in Perl, uses only core modules (tested with v5.8.8)\n>\n>  - There is a small test suite in t/, run individually or with \"prove/*.t\"\n>\n\nI'll give your script a spin on the repo I have here and I'll report\non how it does :-)\n\n-- \nAlex, homepage: http://www.bennee.com/~alex/\nCV: http://www.bennee.com/~alex/cv.php\n"},{"id":"115187","messageId":"4A23A3C8.3090506@yahoo.co.uk","threadId":"19604","inReplyTo":"b2cdc9f30905310042u592a6f5cv541055194524cce0@mail.gmail.com","subject":"Re: [RFC] git-cvs script","fromName":"Nick Woolley","fromEmail":"nickwoolley@yahoo.co.uk","sentAt":"2009-06-01T09:47:52Z","receivedAt":"2009-06-01T09:47:52Z","isPatch":false,"sender":{"key":"nick@noodlefactory.co.uk","avatar":null},"body":"Alex Bennee wrote:\n> If this is using the inbuilt cvsps and perl then it will likely choke\n> on very large CVS repos. For some CVS tree's I've had to resort to a\n> hacked up version of parsecvs to get a conversion running.\n\nI gather cvsps has to read the whole history to be able to interpret the latest\ncommits, is that right? In which case a long history is going to generate long\nwaits on each import. And possibly eat lots of memory too.\n\nI do actually have a larger CVS tree to test it on than I have been using (it's\nabout a decade's worth of changes on a production website) but I didn't want to\nset myself up for a fall by tackling it. For now, my aim has been to keep CVS\n\"out of the living room\" whilst I work on the small CVS module that concerns me.\nMeanwhile, I'm hoping to convince the powers that be that CVS needs to be\nreplaced, preferably with Git, before I get asked to work on something larger.\n\nHowever, if you can test it on your repository, and with your patched version of\nparsecvs, that would be a good thing. Especially if it works.\n\nThanks,\n\nN\n"},{"id":"115192","messageId":"4A23B1AE.1070000@yahoo.co.uk","threadId":"19604","inReplyTo":"7vr5y6xj2a.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] git-cvs script","fromName":"Nick Woolley","fromEmail":"nickwoolley@yahoo.co.uk","sentAt":"2009-06-01T10:47:10Z","receivedAt":"2009-06-01T10:47:10Z","isPatch":false,"sender":{"key":"nick@noodlefactory.co.uk","avatar":null},"body":"Junio C Hamano wrote:\n> If I recall correctly, the above is in line with the original spirit of\n> how git-cvsexportcommit was envisioned to be used by its original authors.\n> \n> That is, the import side is more or less satisfactory done in the sense\n> that it deserved a short and sweet command name, but the export side is\n> not as finished as the import side is, and you have to drive it more\n> explicitly by telling what commit to send back to the CVS side. Building\n> on top of it so the tool keeps track of what needs to be sent, like git-svn\n> allows users to do, would be the right thing to do.\n\nOk - thanks.\n\nApart from fixing significant bugs, for now I've been avoiding making any major\nchanges to git-cvsexportcommit git-cvsimport, since understanding their guts\ntakes a significant amount of time and effort.\n\nOn the other hand, if I ever did, then currently git-cvsexportcommit and\ngit-cvsimport are separate commands. I would imagine they would want to share\nsome code, like \"push\" and \"pull\" operations do in git-cvs. Is that\npossible/encouraged in the current scheme? (e.g. \"use Git::CVS\" - I notice there\nis a Git.pm in the source.) Or would this need to be done by rolling it all\ninto a single command as git-svn seems to do it?\n\n>> - Is this at all useful to anyone else in it's current form?\n> \n> I have to admit that it won't be to me (because I do not interact with CVS\n> myself) but I don't count ;-)\n\nAn enviable position to be in, sir.\n\n\nN\n"}]}