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

[Gregory Szorc]

> On Oct 13, 2015, at 01:12, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
> 
> 
> 
>> On 10/12/2015 10:49 AM, Gregory Szorc wrote:
>> On Mon, Oct 12, 2015 at 7:37 AM, Augie Fackler <raf at durin42.com
>> <mailto:raf at durin42.com>> wrote:
>> 
>>    On Fri, Oct 09, 2015 at 01:10:30PM -0700, Pierre-Yves David wrote:
>>     >
>>     >
>>     > On 10/09/2015 12:33 PM, Gregory Szorc wrote:
>>     > ># HG changeset patch
>>     > ># User Gregory Szorc <gregory.szorc at gmail.com
>>    <mailto: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.
>> 
>>    I agree that it's likely we'll be able to come up with something sane
>>    soon and make clonebundles use it, but I'd like to move forward on the
>>    topic while we sort that out.
>> 
>> 
>> I think I can refactor cmdutil.parsebundletype() into something usable
>> by this feature. If we could just get part 1 and 3 queued, I'd feel much
>> better about things.
> 
> I've taken patch 1 and 3 and pushed them to the clowncopter.
> (check-code wish you an happy thanksgiving)
> 
> 
> I think we should flag the extensions as experimental until the next cycle. What do you think?

The client side support is experimental. So I think it makes sense to mark the server extension as experimental as well.

How do you do that? Docstring?