git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[RFC] Planning a git-cvsdaemon

From
Martin Langhoff <martin.langhoff@gmail.com>
Date
Dec 11, 2005, 02:44 UTC
Message-ID
<46a038f90512101844q326b3d43nf8b40617bd82c576@mail.gmail.com>

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
Next: Mike McCormack
Message 1 of 2 in “[RFC] Planning a git-cvsdaemon”
  1. Martin LanghoffDec 11, 2005
  2. Mike McCormackDec 11, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.