pserver (was Re: [Monotone-devel] Re: Summit brainstorming)

[Nathaniel Smith]

On Sun, Oct 29, 2006 at 12:14:37AM -0700, Graydon Hoare wrote:
> Nathaniel Smith wrote:
> 
> >Check out git-cvsserver.pl, which exposes a read/write (!) interface
> >to a git repo through the pserver protocol...
> >
> >It's not so horrible as it sounds because you get to use the sane,
> >non-CVS model internally; the semantics are reasonably
> >straightforward.  The painful part is implementing pserver, which is a
> >protocol defined more by the quirky implementations you must
> >interoperate with than by a solid spec.
> 
> You know, it's sort of sick but this could kill two birds with one 
> stone. If we make a "--bind-cvs-pserver" option flag for "mtn serve" 
> that multiplexes a pserver command interpreter into the usual sync 
> stream, we'd have a cvs interoperability story *and* the ability to 
> provide partial checkouts ("just use cvs").

This was, err, actually one of the vague motivations spurring me to
think about Chryn -- just because trying to implement multiplexing by
hand is hard enough, never mind trying to deal with two ports and
protocols at the same time :-).  But yeah, it would be an awesome
(albeit, well... tasteless) ability to have.

> I haven't read git-cvsserver.pl, but I'm imagining the semantics of 
> checkin are just "pick a head and try appending the commit there, 
> checking to see that all the files being committed are identical in the 
> head, otherwise complaining"?

I believe that as it goes, it assigns cvs revnos to some privileged
path through the DAG (which can be chosen arbitrarily), and remembers
its decisions.  Then when a client says "hey, here's my update to
foo.c, based on version 1.7", then it finds the tree that had 1.7 in
it, and uses that as the base for the commit.

No idea what it does when the other side tries to send an update
that's actually based against multiple trees or something.

-- Nathaniel

-- 
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould