{"thread":{"id":"2797","subject":"[RFC] Planning a git-cvsdaemon","startedAt":"2005-12-11T02:44:04Z","lastAt":"2005-12-11T20:57:11Z","messageCount":2,"participants":["Martin Langhoff","Mike McCormack"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13468","messageId":"46a038f90512101844q326b3d43nf8b40617bd82c576@mail.gmail.com","threadId":"2797","inReplyTo":null,"subject":"[RFC] Planning a git-cvsdaemon","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-12-11T02:44:04Z","receivedAt":"2005-12-11T02:44:04Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"I am considering working on a git-cvsdaemon script, intended to\nimplement the CVS protocol while reading/writing to a git repo. This\nwould be, of course, limited in what it can do -- I am hoping to be\nable to support initial checkout, diff, log and commit.\n\nMy cunning(?) plan so far is to\n\n - Track only one configurable \"head/branch\" of history and make it\nappear linear. Whenever we have parallel development and then a merge,\npick a side to follow, and then show the merge as one commit. Of\ncourse, it won't do very well with octopus merges, but you shouldn't\nbe doing those anyway, except for bragging purposes ;-)\n\n - Generate a view of the per-file history, so we can maintain\nCVS-style file version numbers.\n\n - Provide enough support to make new commits through CVS, possibly\nwith some kind of delayed-execution commit mechanism. CVS's per-file\natomicity here plays against us big-time, but I think we can fudge\nsomething that works 99% of the time. Commits aborted halfway through\nwill leave a botched commit in GIT too, which someone will hopefully\nidentify and rollback. there is also a time window while we will have\nto be telling CVS that it succeeded in its commit of the initial\nfiles, while we don't know whether the whole commit has succeeded.\nClients committing may be left in an inconsistent state if we fail\nhalfway through.\n\n - The delayed exec commit will need a locking mechanism\n\n - Simplify as much as possible -- ko/kb will probably be ignored, and\nno keyword expansion will be supported. Ignore CVS-style branching,\nand do not worry about tagging.\n\nThe goal is to support command line CVS, and popular GUI CVS clients\n(Eclipse's embedded CVS, TortoiseCVS), and to make it readable, but\nalso writable, so a team can collaborate using GIT and CVS. It is no\nweekend project...\n\nIn any case, I am after feedback in general (and any truly\ninsurmountable issues you can think of),  I haven't found yet  a good\nlibrary implementing the server side of the protocol (other than\ncvs's). git-cvsdaemon will probably take shape in Perl initially,\nthough if there's a good cvs protocol library in other scripting\nlanguage, I'm interested...\n\ncheers,\n\n\nmartin\n"},{"id":"13497","messageId":"439C92A7.4030704@codeweavers.com","threadId":"2797","inReplyTo":"46a038f90512101844q326b3d43nf8b40617bd82c576@mail.gmail.com","subject":"Re: [RFC] Planning a git-cvsdaemon","fromName":"Mike McCormack","fromEmail":"mike@codeweavers.com","sentAt":"2005-12-11T20:57:11Z","receivedAt":"2005-12-11T20:57:11Z","isPatch":false,"sender":{"key":"mike@codeweavers.com","avatar":null},"body":"Martin Langhoff wrote:\n\n> In any case, I am after feedback in general (and any truly\n> insurmountable issues you can think of),  I haven't found yet  a good\n> library implementing the server side of the protocol (other than\n> cvs's). git-cvsdaemon will probably take shape in Perl initially,\n> though if there's a good cvs protocol library in other scripting\n> language, I'm interested...\n\nHey Martin,\n\nThat's a neat idea, and a great way to get projects to move from CVS to GIT.\n\nI'd recommend that you avoid providing commit access to a GIT repository \nvia CVS for starters.  Many projects (eg. Wine) would benefit greatly \nfrom just having a way for people to get the source via CVS without \nhaving to write scripts to maintain a CVS tree in parallel.  Serious \ndevelopers will use GIT if the master repository is GIT anyway.\n\nMike\n"}]}