Unifying sparse and narrow "profiles"

[Durham Goode]

On 3/30/17 2:10 PM, Martin von Zweigbergk wrote:
> On Thu, Mar 30, 2017 at 1:15 PM, Durham Goode <durham at fb.com> wrote:
>>
>> If we make some basic assumptions about the UI (i.e. 'hg sparse' is a good
>> command name, and it will have 'include', 'exclude', 'enable-profile', and
>> 'disable-profile' flags; and .hg/sparse is a good spot to store the client
>> config), I'd almost say let's ship the current sparse extension in hgext/
>> and satisfy mode 0. Then once the narrow-sparse unification has occurred
>> (assuming it implements the same hg sparse UI for mode 0 operations), we can
>> delete the old sparse code.
>
> I'm not ready to make those assumption (and I'm not sure you were
> saying we should). I think we need to discuss UI for the three modes
> Augie mentioned and make sure that they feel consistent.

Yea, I wasn't suggesting we use that exact UI.  I'm just pointing out 
that the UI surface area of sparse is small enough that if we can decide 
on a reasonable UI, we could deliver a mode 0 implementation with 
relatively little effort.

>>
>> That way we can have sparse in 4.3, and there's no pressure to prioritize
>> the narrow refactor until we feel it's necessary. That opens room for
>> potential future refactors in narrowhg as Facebook moves towards a lazy
>> changelog strategy which could influence the public facing narrowness
>> strategy.
>
> For sparse and/or narrow in core, I think we'll need to pass matchers
> around a bit more. We probably will also need to work on matcher
> composition, so we can create a matcher with the user's patterns ANDed
> together with the sparse/narrow matcher. Do you have that problem
> already in the sparse extension? Once we have both sparse and narrow,
> it seems likely we will need to compose those two matchers too.

Yea, sparse hacks around matcher composition at the moment by creating 
bare bones union and negation matcher classes.

https://bitbucket.org/facebook/hg-experimental/src/b5df1d5f3e303a75c550f8e8770afad9945edd86/hgext3rd/sparse.py?at=default&fileviewer=file-view-default#sparse.py-938

It's a bit scary, but actual works remarkably well (though it needs an 
update to handle visitdir for treemanifest).

>>
>>>
>>> (Also, are there any docs I should read about your sparse stuff and
>>> profiles?)
>>
>>
>> `hg sparse --help` is about all we have right now but it's pretty good. Just
>> pay attention to the last sentence in each argument description, since that
>> tells you when the sparse change is applied (i.e. applied when the command
>> is run, or applied when the commit is made)

One other thing, the sparse extension is smart about temporarily pulling 
in files necessary for merge conflicts (like during a rebase, we pull in 
files that are being rebased until the rebase is over). This is very 
useful logic and would need to be ported to narrow as well.