[PATCH 2 of 5 clonebundles V2] clonebundles: filter on bundle type

[Pierre-Yves David]

On 10/09/2015 12:33 PM, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc <gregory.szorc at gmail.com>
> # Date 1444417708 25200
> #      Fri Oct 09 12:08:28 2015 -0700
> # Node ID 1f416cf58a7fb31d94ddee6671637ac51c03be9f
> # Parent  d117d532ed0b3d03c8e4fe85b819964669d1be1a
> clonebundles: filter on bundle type
>
> Not all clients are capable of reading every bundle. This issue of
> format compatibility is addressed by the existing wire protocol bundle
> retrieval workflow. Either the client requests a known format or the
> client sends its capabilities to the server and the server sends down
> a compatible response.
>
> Clone bundles are statically generated before the request (as opposed
> to being dynamically generated such as with the "getbundle" wire
> protocol command). This means that a modern server could produce
> bundles that a legacy client isn't capable of reading. Without
> information in the clone bundles manifest to identify the format of the
> bundle, a client may attempt to download an incompatible bundle, only to
> encounter an unknown format. This could even occur after successfully
> reading most of the bundle (imagine consuming a 1 GB changegroup bundle2
> part only to discover the part following is incompatible). This would
> waste time and resources. And it isn't very user friendly.
>
> Clone bundle manifests thus need to advertise the *exact* format of the
> hosted bundles so clients may filter out entries that they don't know
> how to read. This patch starts to introduce that filtering mechanism.
>
> We introduce the TYPE attribute to declare the entry as a specific type.
> If a client doesn't know how to handle this type, the entry is silently
> ignored.
>
> This patch intentionally does *not* support bundle2. The reason is that
> there is not yet a well-defined way to declare the full type of a
> bundle2 instance. You can't just say "bundle2" or "HG20" because future
> additions to bundle2 may introduce new bundle2 parts or parameters that
> legacy clients aren't able to read. A full "compatibility string"
> (similar to the bundle2 client capabilities advertised during the
> "getbundle" wire protocol command) identifying all the bundle2 parts
> and even their parameters will be required for clients to determine if
> a statically generated bundle2 is compatible with their feature set.
> Defining such a "compatibility string" is scope bloat. It is much easier
> to just not support bundle2 for the time being.
>
> The TYPE attribute is, however, compatible with bundle2 in the future.
> We just need to prefix bundle2 entries with "HG20" and put the
> "compatibility string" afterwards and future clients able to read the
> "HG20" prefix will be able to process bundle2 entries.

Such problem also apply for `hg bundle` and the value of its `hg bundle 
--type TYPE` argument. As we just agree on a format and behavior that 
solve the problem for `hg bundle` we can reuse the same solution for 
this feature.

TL;DR I disagree, bundle2 can works here and should be supported.

-- 
Pierre-Yves David