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

[Gregory Szorc]

On Mon, Oct 12, 2015 at 7:37 AM, Augie Fackler <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>
> > ># 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20151012/8c223f45/attachment.html>