Potential BC changes to sparse before freeze

[Gregory Szorc]

> On Jul 11, 2017, at 11:01, Gregory Szorc <gregory.szorc at gmail.com> wrote:
> 
> Durham, et al:
> 
> 4.3 freeze is in a few days. While we have declared sparse as an experimental feature and not subject to BC, shipping in 4.3 means someone will inevitably use it and be impacted by future BC. (Probably Mozilla for Firefox CI). I'd like to get in as much BC before 4.3 as possible.
> 
> Here are some changes I'm proposing. Are any of them too controversial?
> 
> * Require a [section] in sparse config files. Right now, if there is no section, entries go in [includes]. I think less magic is better. This could break sparse profiles in old revisions in repos using sparse today. Should be easy to monkeypatch over in an extension if you need old behavior. Or we could add a function argument to control parsing strictness.
> 
> * Remove requirement that [excludes] come after [includes]. This seems arbitrary. Requirement may stem from implicit default [includes] section. I doubt this will cause real world bustage.
> 
> * Add a repo requirement to use sparse and add the requirement when sparse is activated on a repo. The way it is today, if you enable sparse then use an old hg or an hg without sparse enabled, the sparse-less hg sees an incomplete working directory and reports a bunch of missing files. Not cool. It feels like we need to lock out clients that aren't sparse aware from interacting with a working directory that has sparse enabled.

I didn't have time for implementing the requirement last week or over the weekend. But I think it is critical we ship sparse with it. I'll try to hack up patches today. If I don't make it before freeze, expect patches against stable.

> 
> I'm also thinking about potentially massive changes to how sparse configs work. Namely, I'd like to unify the file format with hgrc so we don't have N+1 config file formats. That's obviously a massive BC break. And I'm not sure we could land a refactor before the freeze. So we may have to deal with the BC hit in the future.
> 
> Again, I'm trying to walk a tight rope between what is best for Mercurial and that doesn't inconvenience existing sparse users (notably Facebook). I'll try to formulate any patches that make BC changes in such a way that old behavior can be restored easily via an extension.