[Top][All Lists]
[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
- Re: [Monotone-devel] Summit brainstorming, (continued)
- Re: [Monotone-devel] Summit brainstorming, Markus Schiltknecht, 2006/10/26
- Re: [Monotone-devel] Summit brainstorming, Thomas Keller, 2006/10/26
- Re: [Monotone-devel] Summit brainstorming, Christof Petig, 2006/10/27
- Re: [Monotone-devel] Summit brainstorming, Ethan Blanton, 2006/10/27
- Re: [Monotone-devel] Summit brainstorming, Nathaniel Smith, 2006/10/27
- [Monotone-devel] Re: Summit brainstorming, Graydon Hoare, 2006/10/29
- pserver (was Re: [Monotone-devel] Re: Summit brainstorming), Nathaniel Smith, 2006/10/29
- Re: pserver (was Re: [Monotone-devel] Re: Summit brainstorming), Matthew A. Nicholson, 2006/10/31
- [Monotone-devel] Re: pserver (was Re: Re: Summit brainstorming), Graydon Hoare, 2006/10/31
- Re: [Monotone-devel] Summit brainstorming, Christof Petig, 2006/10/29
- [Monotone-devel] Re: Summit brainstorming,
Graydon Hoare <=
- Re: [Monotone-devel] Summit brainstorming, Alex Queiroz, 2006/10/27
- Re: [Monotone-devel] Summit brainstorming, Nathaniel Smith, 2006/10/27
- Re: [Monotone-devel] Summit brainstorming, Alex Queiroz, 2006/10/27
Re: [Monotone-devel] Summit brainstorming, Thomas Keller, 2006/10/25
Re: [Monotone-devel] Summit brainstorming, Matthew A. Nicholson, 2006/10/25
[Monotone-devel] Re: Summit brainstorming, Graydon Hoare, 2006/10/25
Re: [Monotone-devel] Summit brainstorming, Markus Schiltknecht, 2006/10/26