Potential BC changes to sparse before freeze

[Durham Goode]

On 7/11/17 11:01 AM, Gregory Szorc 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.

+1. I don't think we rely on the old behavior anywhere.

> * 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.

Sure, but the docs should be clear that order doesn't matter.

> * 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.

As long as `hg sparse --reset` also remove that requirement.

It'd be nice if the there was some documentation online or such that 
told old-hg users how to recover (remove sparse from .hg/requires && hg 
debugrebuilddirstate && hg revert --all)

> 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.

I'd have to see more details on this.  My concern with hgrc files is 
that config keys can alias very easily, and the composing, multi-owner 
nature of sparse profiles could mean we'd hit this more frequently than 
with hgrcs.

> 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.