fsmonitor: declare missing config options These were added in 4aa57627692a. Attempting to run the test harness with fsmonitor enabled spews a whole bunch of devel warnings due to these options not be declared. Differential Revision: https://phab.mercurial-scm.org/D1176

fsmonitor: warn when fsmonitor could be used fsmonitor can significantly speed up operations on large working directories. But fsmonitor isn't enabled by default, so naive users may not realize there is a potential to make Mercurial faster. This commit introduces a warning to working directory updates when fsmonitor could be used. The following conditions must be met: * Working directory is previously empty * New working directory adds >= N files (currently 50,000) * Running on Linux or MacOS * fsmonitor not enabled * Warning not disabled via config override Because of the empty working directory restriction, most users will only see this warning during `hg clone` (assuming very few users actually do an `hg up null`). The addition of a warning may be considered a BC change. However, clone has printed warnings before. Until recently, Mercurial printed a warning with the server's certificate fingerprint when it wasn't explicitly trusted for example. The warning goes to stderr. So it shouldn't interfere with scripts parsing meaningful output. The OS restriction was on the advice of Facebook engineers, who only feel confident with watchman's stability on the supported platforms. .. feature:: Print warning when fsmonitor isn't being used on a large repository Differential Revision: https://phab.mercurial-scm.org/D894

merge: additional test cases to show merge-halting behavior In the previous patches, we allowed the user to specify that a merge process should be halted when a filemerge fails. This patch adds tests that show additional places this logic can be utilized -- via the options to do additional post-filemerge checks to determine if a file merge was successful. Differential Revision: https://phab.mercurial-scm.org/D952

rebase: add support to output nodechanges This patch adds support to rebase to show the changes in node once the rebase is complete. This will be extremely helpful for automation purposes and editors such as Nuclide. The output is a dictionary of predecessor hash as key and a list of successors' hashes. The successors one is a list as there can be many successors for a single predecessor in case of split and it will good to have a generic output format. This patch adds tests for the same. A new file is created for the patch as existing files related to rebase has their own purpose and there will be more formatter support coming for rebase in next cycle. Thanks to Jun for suggesting to use fm.data(). Differential Revision: https://phab.mercurial-scm.org/D1173

ui: move request exit handlers to global state Since the ui objects can be created with the 'load' class method, it is possible to lose the exit handlers information from the old ui instance. For example, running 'test-bad-extension.t' leads to this situation where chg creates a new ui instance which does not copy the exit handlers from the earlier ui instance. For exit handlers, which are special cases anyways, it probably makes sense to have a global state of the handlers. This would ensure that the exit handlers registered once are definitely executed at the end of the request. Test Plan: Ran all the tests without '--chg' option. This also fixes the 'test-bad-extension.t' with the '--chg' option. Differential Revision: https://phab.mercurial-scm.org/D1166

sparse-read: skip gaps too small to be worth splitting Splitting at too small gaps might not be worthwhile. With this changeset, we stop considering splitting on too small gaps. The threshold is configurable. We arbitrarily pick 256K as a default value because it seems "okay". Further testing on various repositories and setups will be needed to tune it. The option name is 'experimental.sparse-read.min-gap-size`, and replaces `experimental.sparse-read.min-block-size` which is not used any more.

sparse-read: move from a recursive-based approach to a heap-based one The previous recursive approach was trying to optimise each read slice to have a good density. It had the tendency to over-optimize smaller slices while leaving larger hole in others. The new approach focuses on improving the combined density of all the reads, instead of the individual slices. It slices at the largest gaps first, as they reduce the total amount of read data the most efficiently. Another benefit of this approach is that we iterate over the delta chain only once, reducing the overhead of slicing long delta chains. On the repository we use for tests, the new approach shows similar or faster performance than the current default linear full read. The repository contains about 450,000 revisions with many concurrent topological branches. Tests have been run on two versions of the repository: one built with the current delta constraint, and the other with an unlimited delta span (using 'experimental.maxdeltachainspan=0') Below are timings for building 1% of all the revision in the manifest log using 'hg perfrevlogrevisions -m'. Times are given in seconds. They include the new couple of follow-up changeset in this series. delta-span standard unlimited linear-read 922s 632s sparse-read 814s 566s

subrepo: implement 'unshare' for Mercurial subrepos I think there's a slight hole here in that a subrepo could be shared, removed from .hgsub, and then it's not part of context.substate (so not iterated over). But the push command has the same hole IIRC, and I think removing a subrepo is an edge case. The import hack is a copy/paste of subrepo.subrepo().

share: move the implementation of 'unshare' to the 'hg' module This will be used to setup unsharing subrepos. Usually cmdutil is used for this purpose. But the implementation needs hg.copystore(), and the hg module already imports cmdutil.

show: use labelcset() template alias for work (and stack) views By reusing labelcset() template alias from map-cmdline.default we can now display obsolescence information in `hg show work/stack`.