[PATCH RFC] batching: new module to support batching of commands
Matt Mackall
mpm at selenic.com
Fri Jun 3 21:27:34 UTC 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