[PATCH 5 of 5] exchange: refactor APIs to obtain bundle data (API)

Augie Fackler raf at durin42.com
Tue Sep 27 10:20:33 EDT 2016

On Tue, Sep 27, 2016 at 03:45:34PM +0200, Pierre-Yves David wrote:
> On 09/25/2016 10:42 PM, Gregory Szorc wrote:
> ># HG changeset patch
> ># User Gregory Szorc <gregory.szorc at gmail.com>
> ># Date 1474830761 25200
> >#      Sun Sep 25 12:12:41 2016 -0700
> ># Node ID f6bb4ff0a8c47b099157e615a2874c193ac77512
> ># Parent  2dc93677a8836d2365b561d1ba79f62ff68a4f23
> >exchange: refactor APIs to obtain bundle data (API)
> >
> >Currently, exchange.getbundle() returns either a cg1unpacker or a
> >util.chunkbuffer (in the case of bundle2). This is kinda OK, as
> >both expose a .read() to consumers. However, localpeer.getbundle()
> >has code inferring what the response type is based on arguments and
> >converts the util.chunkbuffer returned in the bundle2 case to a
> >bundle2.unbundle20 instance. This is a sign that the API for
> >exchange.getbundle() is not ideal because it doesn't consistently
> >return an "unbundler" instance.
> I wonder how much this is used in extension. Should we keep the old API with
> a deprecation warning for a version ?

Spot-checking, hgsubversion, hg-git, and narrowhg all don't need to
touch this. Given the, um, involved jiggery pokery that narrowhg is
doing on bundle streams, I think it's *probably* safe to ditch this
without a deprecation warning period.

More information about the Mercurial-devel mailing list