monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: Summit brainstorming


From: Graydon Hoare
Subject: [Monotone-devel] Re: Summit brainstorming
Date: Tue, 31 Oct 2006 20:58:09 -0800
User-agent: Thunderbird 1.5.0.7 (Windows/20060909)

Christof Petig wrote:

I would rather complete partial pull for monotone than to start coding a
cvs server (or porting git-cvsserver). I have suffered from CVS protocol
variations on the client side enough for this life! ;-)

Fair enough. I think actually the way I'd want to do this is in a few separate pieces, to gain a bit of reuse along the way:

  1. Make up a few new "imperative" netcmd packet types for the netsync
     protocol:

     - a "send-a-glob-selected-portion-of-the-served-certs" command
     - a "send-a-subgraph-of-the-revision-graph" command
     - a "send-a-rev" command
     - a "send-a-file / file-delta" command
     - a "receive-a-rev-plus-N-files" command
     - a "receive-a-cert" command

     I know this breaks the (imo lovely) promise of "all network
     operations are informative, not transactional", but that's sort of
     a meaningless distinction when you're talking about stateless
     clients. Oh well. I also realize that there's some near-overlap
     with automate commands here, but I think the use-cases are
     sufficiently different to make it acceptable to keep the facilities
     separate.

  2. Make the accept() loop also take an option to listen on an extra
     port, and when it sees a connection on that port, fork off a
     subprocess-on-a-pipe that speaks authenticated netsync back to
     itself.

  3. Optionally: write a program that runs "client side" and performs a
     limited subset of monotone functions (checkout, update, merge,
     commit, diff, log?) against an "imperative mode" server.

  4. Optionally: write a program that translates CVS pserver commands
     into the imperative netsync commands, that runs server-side
     pretending to be a CVS server.

  5. Optionally: write any number of similar programs to translate
     other tools' command streams into imperative netsync commands.

You have the (IMHO nicer) alternatives of
- bidirectional cvssync (once initial push is supported, for now you
have to start with the cvs repository)
- monotone<->git synching (which is _much_ more useful than a cvs server)

Agreed. A git interop module would be nice. Or an hg interop module. Or bzr. Or something... the landscape has many competitors at the moment.

-graydon





reply via email to

[Prev in Thread] Current Thread [Next in Thread]