[PATCH RFC] batching: new module to support batching of commands

Matt Mackall mpm at selenic.com
Fri Jun 3 16:27:34 CDT 2011


On Fri, 2011-06-03 at 08:16 +0200, Peter Arrenbrecht wrote:
> On Thu, Jun 2, 2011 at 6:59 PM, Matt Mackall <mpm at selenic.com> wrote:
> > On Thu, 2011-06-02 at 18:18 +0200, Peter Arrenbrecht wrote:
> >> # HG changeset patch
> >> # User Peter Arrenbrecht <peter.arrenbrecht at gmail.com>
> >> # Date 1307031409 -7200
> >> # Node ID 9946e78354feb1651953dfd65009a005fb0d3dd9
> >> # Parent  1ffeeb91c55d0b00445ceabde14a0d0faf906a33
> >> batching: new module to support batching of commands
> >
> > Let's give it a different name to make it clear it's attached to the
> > wire protocol.
> 
> I think it should live in repo.py. It will have to be used by
> localrepository and all the wirerepository-descendants so they
> uniformly support the batch() call.
> 
> > Remind me why we need this with the new discovery protocol?
> 
> Need is a bit of a strong word here. But: right now we immediately
> send heads and stop if remote is a subset of local. Otherwise we build
> and send the first sample, starting setdiscovery. So heads() and
> known(firstsample) could actually be batched, but then we would always
> incur the overhead of building and transmitting the first sample, even
> when remote is a subset (we discussed this at the sprint and you
> convinced me to keep the initial roundtrip very light).

Ok, sure. There are probably other things that will benefit, like
batching pushkey operations.

> > Is there any point batching local operations? Shouldn't they just be
> > fulfilled immediately and have submit do nothing?
> 
> One might choose not to call submit() on the batch, so it's a more
> consistent API this way.

Good point.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list