[PATCH RFC] wireproto: add support for batching of some commands

[Peter Arrenbrecht]

On Mon, Mar 14, 2011 at 7:44 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Mon, 2011-03-14 at 10:07 +0100, Peter Arrenbrecht wrote:
>> # HG changeset patch
>> # User Peter Arrenbrecht <peter.arrenbrecht at gmail.com>
>> # Date 1300093067 -3600
>> wireproto: add support for batching of some commands
>>
>> Allows clients to send batches of server commands in one roundtrip. An
>> example is provided in the contained test.
>>
>> This is desirable for the new discovery protocol. For example, in a later
>> patch we will batch the request for the server's heads with the one where
>> the server checks if it knows the client's heads, eliminating one roundtrip
>> out of 4 for a pull where local is a subset of remote.
>
> It'd be really nice if you explained how it worked. There's a lot here I
> don't understand.
>
> I can't find the part where the batched command automatically falls back
> to serial commands so that client code doesn't have to implement
> fallback on its own.

Matt, good point. This approach introduces separate code paths which
make good test coverage harder. I'll post a better patch soonish.

In a similar vein, the current prototype work for new discovery treats
local and remote repos differently. For local repos, it simply
computes the set of common heads directly, since it has access to both
graphs in full. But this would probably mean we'd have to run the test
suite in its entirety for both local and for remote behaviour (à la
--pull). Much like we currently have a flag for tests with inotify
active. Does not make me happy.

One reason for the separate code paths is that so far new discovery
can be a tad CPU intensive, which is only worth it if it saves a lot
of roundtrips. We shall definitely try to optimize this further, but
I'd like to know how you feel in general about such different code
paths (local vs. remote).

-parren