git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] Planning a git-cvsdaemon
@ 2005-12-11  2:44 Martin Langhoff
  2005-12-11 20:57 ` Mike McCormack
  0 siblings, 1 reply; 2+ messages in thread
From: Martin Langhoff @ 2005-12-11  2:44 UTC (permalink / raw)
  To: Git Mailing List

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [RFC] Planning a git-cvsdaemon
  2005-12-11  2:44 [RFC] Planning a git-cvsdaemon Martin Langhoff
@ 2005-12-11 20:57 ` Mike McCormack
  0 siblings, 0 replies; 2+ messages in thread
From: Mike McCormack @ 2005-12-11 20:57 UTC (permalink / raw)
  To: Martin Langhoff; +Cc: Git Mailing List

Martin Langhoff wrote:

> 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...

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-12-11 20:56 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-11  2:44 [RFC] Planning a git-cvsdaemon Martin Langhoff
2005-12-11 20:57 ` Mike McCormack

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).