[RFC] Planning a git-cvsdaemon

I am considering working on a git-cvsdaemon script, intended to implement the CVS protocol while reading/writing to a git repo. This would be, of course, limited in what it can do -- I am hoping to be able to support initial checkout, diff, log and commit.

My cunning(?) plan so far is to

 - Track only one configurable "head/branch" of history and make it
appear linear. Whenever we have parallel development and then a merge,
pick a side to follow, and then show the merge as one commit. Of
course, it won't do very well with octopus merges, but you shouldn't
be doing those anyway, except for bragging purposes ;-)

 - Generate a view of the per-file history, so we can maintain
CVS-style file version numbers.

 - Provide enough support to make new commits through CVS, possibly
with some kind of delayed-execution commit mechanism. CVS's per-file
atomicity here plays against us big-time, but I think we can fudge
something that works 99% of the time. Commits aborted halfway through
will leave a botched commit in GIT too, which someone will hopefully
identify and rollback. there is also a time window while we will have
to be telling CVS that it succeeded in its commit of the initial
files, while we don't know whether the whole commit has succeeded.
Clients committing may be left in an inconsistent state if we fail
halfway through.

 - The delayed exec commit will need a locking mechanism

 - Simplify as much as possible -- ko/kb will probably be ignored, and
no keyword expansion will be supported. Ignore CVS-style branching,
and do not worry about tagging.

The goal is to support command line CVS, and popular GUI CVS clients (Eclipse's embedded CVS, TortoiseCVS), and to make it readable, but also writable, so a team can collaborate using GIT and CVS. It is no weekend project...

In any case, I am after feedback in general (and any truly insurmountable issues you can think of), I haven't found yet a good library implementing the server side of the protocol (other than cvs's). git-cvsdaemon will probably take shape in Perl initially, though if there's a good cvs protocol library in other scripting language, I'm interested...

cheers,

martin

Martin Langhoff wrote:

Hey Martin,

That's a neat idea, and a great way to get projects to move from CVS to GIT.

I'd recommend that you avoid providing commit access to a GIT repository via CVS for starters. Many projects (eg. Wine) would benefit greatly from just having a way for people to get the source via CVS without having to write scripts to maintain a CVS tree in parallel. Serious developers will use GIT if the master repository is GIT anyway.

Mike