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/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.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
