[PATCH 1 of 3 v2] bundle2: store list of bundled nodes and heads in bundle20 instance

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Jun 2 03:34:00 CDT 2015

On 06/01/2015 08:56 PM, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc <gregory.szorc at gmail.com>
> # Date 1432593644 25200
> #      Mon May 25 15:40:44 2015 -0700
> # Node ID 2c67a5830d8dfcb3c76d9a171abe18c19caf05db
> # Parent  eb52de500d2a308761b65bc9efaf85272c27eca5
> bundle2: store list of bundled nodes and heads in bundle20 instance
> bundle2 provides the ability to store and transfer extra metadata
> through parts. Part generators may wish to transfer per-changeset
> data. Because this may be a common operation, part generators will
> want a way to quickly access the list of changesets contained in the
> bundle. This patch implements such a feature.

I'll insist on the fact we do not need such feature to get the 
.hgtagscache version running. Maybe we'll need such stuff to optimize it 
later but we will not get better result with such data for now.

Getting this part right is not trivial and delaying the core work.

> We add "bundlednodes" and "bundledheads" attributes to the
> bundle20 class which hold the list of changesets and heads,
> respectively, in the bundle.

The right way to store such information is an outgoing object because 
code who use such information always end up needing a different facet of it.

But we do not need this information to get the other patch in so lets 
delay this.

> Part generators are passed "missing" and "heads" arguments today.
> It may be tempting for part generators to key off of these to
> compute the set of missing nodes or heads. However, doing so may
> not always be correct!

> With remote changegroups, the client may be
> instructed to apply a remote bundle2 that already contains the
> metadata a part handler may add.

We do not have such capacity now. The "remote-changegroup" part is 
currently limited to bundle1 only. So there is no meta data to reuse for 

> In this scenario, if the part
> handler keyed off the "missing" and "heads" arguments passed to
> it, it may redundantly transfer data that was included in the remote
> bundle2. By having the changegroup part generator explicitly record
> the changesets and heads in the bundle, we prevent this potential
> redundant transfer of data.

The bundle20 class is an agnostic generator of binary 'HG20' stream. The 
parts in this stream could contains cat-gif, diplomatic-cable, 
love-letter, or Mercurial related payload.

If something needs to carry data about the creation of a bundle, it 
should be done in a distinct object. For example. The pushoperation 
object is holding such roll.

In a similar way, data about unbundled content is stored in the 
'bundleoperation' instead of the unbundler itself.

(But again, we do not need any of that for now)

Pierre-Yves David

More information about the Mercurial-devel mailing list