On Thu, Mar 30, 2017 at 2:34 PM, Durham Goode <dur...@fb.com> wrote: > > > On 3/30/17 2:10 PM, Martin von Zweigbergk wrote: > >> On Thu, Mar 30, 2017 at 1:15 PM, Durham Goode <dur...@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/b5df1d5f3 > e303a75c550f8e8770afad9945edd86/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. >
How about this for a concrete proposal (with intent on landing some bits of sparse in 4.3): 1) Drop a copy of Facebook's sparse.py into hgext/ along with minimally-modified tests 2) Mark extension as experimental and not subject to any BC guarantees 3) Rename "sparse" command to "debugsparse" until we have a proper UX bikeshed 4) Start moving code from extension into core where appropriate. This will help flush out what considerations core needs to make for maintaining sparse checkouts 5) Attempt to stabilize the sparse profiles file format so daring consumers can use sparse checkouts in 4.3 without major BC concerns from file formats 6) Bikeshed and paint the shed 7) Repeat #6 8) (a few releases later) drop experimental labeling and/or move sparse checkout into core as a feature that is enabled by default (presumably this is gated on a "sign-off" from narrow clone)
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
