[PATCH 1 of 3] bundle: allow creation of changegroup3 bundles

[Gregory Szorc]

On Thu, May 4, 2017 at 12:14 PM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 05/04/2017 07:04 PM, Martin von Zweigbergk via Mercurial-devel wrote:
>
>> # HG changeset patch
>> # User Martin von Zweigbergk <martinvonz at google.com>
>> # Date 1458952398 25200
>> #      Fri Mar 25 17:33:18 2016 -0700
>> # Node ID f4b255ff67d05e329cc3d80ce1552f30005f58e9
>> # Parent  06058cbb9209df54bfa0aaf9f7d10b836a1e3ee9
>> bundle: allow creation of changegroup3 bundles
>>
>> With this change, one can use "hg bundle -t v3" to creat changegroup3
>> bundles, which support treemanifests and revlog flags. In treemanifest
>> repos, v3 is the default bundle format.
>>
>
> The bundle spec "version" cover a collection of setting for the underlying
> content. It is not directly correlated to the changegroup version.
>
> Tree manifest is still experimental so it seems a bit early to burn a new
> bundle spec version on this especially since we have other bundle
> improvement coming (phase, tag cache, obsmarkers, etc).
>
> So I don't think we should introduce a new bundlespec version yet. Instead
> I would recommend the following:
>
> 1) introduce a parameter to control de cg-version (cgversion=03?)
> 2) automatically bump the cg version to '03' if no spec is passed and tree
> manifest is used,
> 3) late in the 4.3 cycles consider introducing a v3 with all the new
> improvements (if some make sense at the user-visible feature level).
>

There was confusion about this in IRC.

I agree with what Pierre-Yves said: while this will require a "v3" to
support cg3, it is still a bit too early in cg3's support cycle to
introduce a stable, user-facing bundle spec version. Until we have a better
API for controlling bundle generation via bundle specs, I think this should
be hacked in via an experimental config option while recycling "v2."
Alternatively, we can name the version "expcg3" or something less stable
and rename it (presumably to "v3") once the feature is stable. The latter
will make it much easier to test the feature and won't result in
accidentally producing "v2" bundles that legacy clients choke on.

The concern with the "vN" versions is that every Mercurial client with
knowledge of that version string has to be capable of handling any future
bundle generated with that same "vN" version (or have code for filtering
from other data in the clone bundles manifest, preferably from BUNDLESPEC).
This means every time there is a new required bundle part, we have to
invent a new "vN" or find some other way to alter clonebundles entries so
old clients know they can't consume them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170504/e9c9f9b5/attachment.html>