[PATCH] wireproto: support disabling bundle1 only if repo is generaldelta

[Matt Mackall]

On Sun, 2015-12-20 at 12:28 -0800, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc <gregory.szorc at gmail.com>
> # Date 1450641384 28800
> #      Sun Dec 20 11:56:24 2015 -0800
> # Node ID a57fec21e479844c0ee493b727d9659698fc8352
> # Parent  ff305ab2e0d7291da12a8b640ce8c9bb28e0cb03
> wireproto: support disabling bundle1 only if repo is generaldelta
> 
> I recently implemented the server.bundle1* options to control whether
> bundle1 exchange is allowed. Initially, I implemented them as simple
> boolean options.
> 
> After thinking about Mozilla's strategy for handling generaldelta
> rollout a bit more, I think server operators need an additional
> lever: disable bundle1 if and only if the repo is generaldelta.
> 
> bundle1 exchange for non-generaldelta repos will not have the potential
> for CPU explosion that generaldelta repos do. Therefore, it makes sense
> for server operators to continue to allow bundle1 exchange for
> non-generaldelta repos without having to set a per-repo hgrc option
> to change the policy depending on whether the repo is generaldelta.
> 
> This patch introduces a new string value for the server.bundle1*
> options that disallows bundle1 for generaldelta repos.
> 
> This new value enables server operators to limit the bundle1 restriction
> to the class of repos that can cause performance issues. It also allows
> server operators to tie bundle1 access to store format. In many server
> environments (including Mozilla's), legacy repos will not be
> generaldelta and new repos will or might be. New repos often aren't
> bound by legacy access requirements, so setting a global policy that
> disallows access to new/generaldelta repos via bundle1 could be a
> reasonable policy in many server environments. This patch makes this
> policy very easy to implement (modify global hgrc, add options to
> existing generaldelta repos to grandfather them in).
> 
> This patch shines light on a possibly missing ui.config* API to
> retrieve a value as a boolean or as a string. check-config doesn't
> allow treating values as multiple types, so I had to reimplement part
> of configbool() inline in this patch. I'm not sure if this pattern is
> common enough to warrant a new ui.config* method.

I'm of the opinion we should apply more brain cells to the problem of avoiding
pseudo-boolean options. They're slightly convenient (as are exceptions to rules
in general) but they're confusing for users and developers alike.

Can I suggest: bundle1gd boolean, defaulting to true? Combined with bundle1 via
and.
-- 
Mathematics is the supreme nostalgia of our time.