merge with stable

match: make exactmatcher.visitchildrenset return file children as well Previously, if we had an exactmatcher like ['foo.txt', 'a/bar.txt', 'a/b/c/baz.txt'], we'd get back the following data: '.': {'a'} 'a': {'b'} 'a/b': {'c'} 'a/b/c': 'this' 'a/b/c/d': set() This was incorrect, since visitchildrenset explicitly says not to pay attention to 'foo.txt' and 'a/bar.txt' by not returning them or 'this'. Given the near impossibility of making visitchildrenset reliabbly produce only subdirectories, a previous commit has made it documented and expected that visitchildrenset can return a set containing both files and subdirectories to visit, instead of implying/requiring that visitchildrenset() return 'this' if there are files to visit. This makes the code for exactmatcher match this clarified documentation. Differential Revision: https://phab.mercurial-scm.org/D4365

match: document that visitchildrenset might return files At least when using includematcher, and probably most matchers, we do not know if a/b/f refers to a file 'f' in a/b, or a subdirectory 'f' in a/b, so most matchers will return {'f'} for visitchildrenset('a/b'). Arguably, all matchers could/should - for exactmatcher, we know that 'f' is a file, but there's no reason to return 'this' for visitchildrenset('a/b') causing code to investigate 'a/b/x', for example. Differential Revision: https://phab.mercurial-scm.org/D4364

util: make timedcm require the label (API) Differential Revision: https://phab.mercurial-scm.org/D4350

cleanup: make all uses of timedcm specify what they're timing It's not used in the timing itself, but it's valuable for the trace events we emit. Differential Revision: https://phab.mercurial-scm.org/D4349

util: make timedcm context manager also emit trace events Differential Revision: https://phab.mercurial-scm.org/D4348

demandimport: instrument python 2 code with trace events This causes the evaluation of an import in Python 3 to emit some trace data. There's some interesting wrinkles in here, like the fact that before we even hit dispatch we've demand-imported `sys` several times, despite the fact that `sys` was already fully loaded as one of the first few statements in the `hg` script. I don't think that's actually costing us a ton of performance, but it's probably something we should investigate fixing some day. Differential Revision: https://phab.mercurial-scm.org/D4347

dispatch: have dispatch.dispatch and dispatch._runcatch emit trace events Differential Revision: https://phab.mercurial-scm.org/D4345

tracing: new module to make tracing events in hg easier This lives in hgdemandimport because I want to instrument a bunch of low-level stuff including the bare `hg` script and demandimport, so it can't live at a higher layer. Differential Revision: https://phab.mercurial-scm.org/D4344

tests: add support for emitting trace events to run-tests Right now this is pretty basic, but it's a start. Differential Revision: https://phab.mercurial-scm.org/D4343

contrib: new script to read events from a named pipe and emit catapult traces I'm starting to get more serious about getting some insight into where we're spending our time, both in hg itself but also in the test suite. As a first pass, I'm going to try and produce catapult traces[0] that can be viewed with Chrome's `about:tracing` tool. 0: https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/edit#heading=h.nso4gcezn7n1 Differential Revision: https://phab.mercurial-scm.org/D4342

fastannotate: pconvert paths from the server for Windows I'm guessing that the right thing to do here is to convert the paths on the server, but I know this is a WIP, and I don't know where that needs to happen. I'm just trying to eliminate the malicious path warnings in the tests.

test-fastannotate: close fd before unlinking to keep Windows happy

test-fastannotate: fix trivial output differences on Windows

fastannotate: make the default value for `fastannotate.useflock` dynamic fcntl.flock isn't available on Windows.

narrow: add a --narrowspec flag to clone command This patch adds a --narrowspec flag to `hg clone` command in narrow extension which can be used to read a file and parse narrowspecs from it and use it while cloning a repository. The --narrowspec flag assumes that the user wanted to narrow the clone. Tests are added both for ellipsis and non-ellipsis mode. Differential Revision: https://phab.mercurial-scm.org/D4156

manifest: use rev() instead of nodemap.__contains__ nodemap is an implementation detail of revlogs and isn't appropriate to expose on the manifest storage API. While revlogs don't have a __contains__, they do have lookup() for resolving a value to a node. And this calls rev(), whose API is documented to raise LookupError if a node doesn't exist. And the parameters to LookupError are identical to what was being raised here. So this change should be backwards compatible. Differential Revision: https://phab.mercurial-scm.org/D4279

manifest: rename manifestlog._treeinmem to ._treemanifests Not sure what "inmem" was supposed to indicate. This object is an interface to manifest data on disk as well as "in memory" (assuming that's what "inmem" means). Differential Revision: https://phab.mercurial-scm.org/D4278

manifest: add getstorage() to manifestlog and use it globally It is a common pattern to obtain a directory manifest storage instance (a manifestrevlog) by going through manifestlog._revlog.dirlog(). Why access to storage and caching of other manifests is done through manifestrevlog instead of manifestlog, I don't know. This commit establishes a getstorage(tree) API on manifestlog and imanifestlog that provides a public API for accessing manifest storage. All consumers previously using private attributes have been updated to use this new method. .. api:: manifestlog now has a getstorage(tree) method It should be used for obtaining an object representing the manifest's storage implementation. Accessing manifestlog._revlog should be avoided. Differential Revision: https://phab.mercurial-scm.org/D4277

manifest: rename dir argument and attribute to tree dir shadows a built-in. We use it throughout the manifest code, which is unfortunate. This commit updates just manifestrevlog to be more well behaved. .. api:: renamed manifest.manifestrevlog.__init__ dir argument to tree Differential Revision: https://phab.mercurial-scm.org/D4276

manifest: set appropriate cache entry when clearing _dirlogcache() manifestrevlog applies to any manifest, not just the root manifest. Resetting the cache and populating its root entry with self is not correct when the instance does not refer to the root manifest. This has no test fallout. So I'm guessing we only ever call clearcaches() on the root manifest. Or we have no test coverage that are impacted by a bad cache on a non-root manifestrevlog. Differential Revision: https://phab.mercurial-scm.org/D4275

manifest: remove addgroup() from manifestlog and imanifestlog addgroup() is part of the storage interface for manifests. Unfortunately, we don't yet have a formal storage interface for manifests. (One will be established in subsequent commits.) One thing is for sure, addgroup() doesn't belong on imanifestlog - at least not unless we extend that interface to encompass storage. For now, let's access addgroup() on the _revlog attribute, just like we do for tree manifests. Even though this violates visibility, it is consistent. Differential Revision: https://phab.mercurial-scm.org/D4274

repository: clarify role of imanifestlog Looking at the implementation of manifest.manifestlog, it is highly tailored towards servicing the root manifest. So clarify that in the interface docstring. Differential Revision: https://phab.mercurial-scm.org/D4273

changegroup: change topics during generation Changegroup generation and consumption currently uses different sets of topics. Generation uses "bundling" and consumption uses the name of the thing being consumed. This commit makes the topic and unit names consistent on both ends. The reason I chose to change the generation side is because when "bundling" is used for 3 different stages, it is unclear which stage of changegroup generation we're in. By making the topics "changesets," "manifests," and "files," one can get a better feel for how far along in the bundling process we are. Differential Revision: https://phab.mercurial-scm.org/D4272