[PATCH 01 of 13 sparse] sparse: vendor Facebook-developed extension

[Augie Fackler]

> On Jul 5, 2017, at 18:48, Martin von Zweigbergk <martinvonz at google.com> wrote:
> 
> On Wed, Jul 5, 2017 at 3:37 PM, Augie Fackler <raf at durin42.com> wrote:
>> 
>>> On Jul 5, 2017, at 18:34, Gregory Szorc <gregory.szorc at gmail.com> wrote:
>>> 
>>>> I'm happy to see sparse in tree and in core. There are some things we
>>>> need to discuss, but I think we can discuss those as things are being
>>>> moved into core. For example, should "hg clone --include X" be a
>>>> narrow clone of files (and directories, if using treemanifests)
>>>> matching X or a full clone with a sparse checkout of files matching X?
>>>> 
>>> I'm going to defer integrating sparse with commands as long as possible. Before we even talk about UX, I'd like to get the "profiles" formalized so they are compatible with narrow. Right now, the profiles are strictly files in the checkout. But presumably we'll also want a way to specify the depth and "width" of files and changelog history to facilitate narrow and shallow clone. I can make a compelling argument that all these properties should be defined in the same "profile." That means designing the profiles so they can be extended to narrow and shallow later.
> 
> Note that shallowness is mostly orthogonal from narrowness (I know
> Augie knows that already, I'm pointing it out to others). I'd like to
> move the narrowness pieces into core first, then the shallowness
> pieces, because the latter is much clear how to handle (for example,
> it affects discovery).
> 
>> I don't think this should be too much work, especially if we're willing to break BC in certain ways when we introduce narrow/shallow (like having a clone using a sparse profile imply a narrow clone).
> 
> What do we put in these profiles? I only know they contain paths that
> are part of the sparse checkout. The way narrowhg currently works, it
> cannot change from revision to revision (because that would make "hg
> checkout" etc talk to the server to download new filelogs), so unless
> we reconsider that, we can't have any of it in a profile that's under
> version control.

That's a wrinkle, yeah. Or you have to do some sort of awful 'checkout --widen-to-both' dance.

We could (for a first pass) only ever automatically widen the spec, and require human intervention (via an `hg sparse` or `hg tracked` command) to narrow back down to the current spec.

> 
>> 
>> Yeah, if we can figure out how to define profiles cleanly so that they're narrow compatible, that'll be awesome.
>> 
>> Things narrow wants to set, for consideration:
>> 
>> * should narrow be active, or the store be full?
>> * depth of clone (if the first is yes)
>> * should changes outside the tracked spec be elided? (if the first is yes)
>> 
>> That's all I can think of offhand.