discovery: move children computation in its own method This clarifies the main logic and starts to pave the way to some caching.

discovery: simplify the building of the children mapping Since we only care about the revisions inside the set we are sampling, we can use simpler code (and probably sightly faster).

discovery: simply walk the undecided revs when building the children mapping The sampling only care about revisions in the undecided set, so building children relationship within this set is sufficient. The set of undecided changesets can be much smaller than the full span from its smallest item to the tip of the repository. This restriction can significantly speed up operations in some cases. For example, on our private pathological case, this speeds things up from about 53 seconds to about 7.5 seconds.

discovery: use a lower level but faster way to retrieve parents We already know that no revision in the undecided set are filtered, so we can skip multiple checks and directly access lower level data. In a private pathological case, this improves the timing from about 70 seconds to about 50 seconds. There are other actions to be taken to improve that case, however this gives an idea of the general overhead.

discovery: avoid computing identical sets of heads twice The very same set of heads is computed in the previous statement, it seems more efficient to just copy that result.

discovery: moved sampling functions inside discovery object In this patch, we transform the sampling functions into methods of the `partialdiscovery` class in the Python case. This will provide multiple benefit. For example we can keep some cache from one sampling to another. In addition this will help the Oxidation work as all graph traversal related logic will be contained in a single object.

discovery: rename `srvheads` to `knownsrvheads` The `srvheads` variable only contains the known set of remove heads. Renaming the variable make it clearer.

verify: small refactoring and documentation in `_verifymanifest` Small changes to make this area of code clearer.

verify: document the `_verifymanifest` method

verify: document `_verifychangelog` We document the method input, output and checks.

verify: rename the `checklog` to `_checkrevlog` The method is for internal use only. In addition we make the method name explicitly contains `revlog` to make it clearer it is checking higher level revlog properties.

verify: document the `checklog` method Let us add details about what the function is expected to do.

revlog: add some documentation to the `checksize` method I had to look at it, so I figured I would leave some documentation for the next person seeking information.

verify: make `checkentry` a private method This method is for internal use only.

verify: document the `checkentry` method This method checks various core propertes of a revision. We document inputs, outputs and the checks performed.

verify: add some inline documentation to the top level `verify` method The goal is to clarify each section goal.

verify: explicitly return 0 if no error are encountered Relying on the fact None is treated as 0 by other logics seems smarter than we should be.

verify: minimal documentation for `verifier.verify` I expect the docstring to grow over time, so lets start small.

verify: make the `exc` method private The method is for internal use only.

verify: document the `exc` method Simple method, get simple documentation.

verify: make `err` a private method The method is for internal use only.

verify: document the `err` method Simple method get simple documentation.

verify: make the `warn` method private The method is for internal use only. Let us make that fact clearer.

verify: document the `warn` method This is the first bit of an effort to document and augment the verify code.

uncommit: add flag --allow-dirty-working-copy This adds a flag `--allow-dirty-working-copy` as an alias for the experimental config option `experimental.uncommitondirtydir`. Differential Revision: https://phab.mercurial-scm.org/D6069

uncommit: don't allow dirty working copy with PATH (issue5977) On a dirty PATH, uncommit was working without even setting the config `experimental.uncommitondirtydir` to `True`. Ideally, it should abort as it does for a dirty dir. This patch makes uncommit to require the config option `experimental.uncommitondirtydir` on a dirty PATH. Original patch to evolve extension authored by Dan Villiom Podlaski Christiansen: https://bitbucket.org/octobus/evolve-devel/pull-requests/8/bug-5977-uncommit-dirtiness/diff Differential Revision: https://phab.mercurial-scm.org/D5940

cleanup: remove two bogus test names from python3 list I suspect one of these was a typo from the start, the other appears to have become a .t test at some point. Differential Revision: https://phab.mercurial-scm.org/D6076

revlog: preserve `_lazydelta` attribute in `revlog.clone` The attribute was introduce in 688fc33e105d, Yuya Nishihara pointed out that this preservation was missing. This changeset fixes the preservation and make sure we set the attribute according the modes.

localrepo: explicit `_lock` arguments in `lock` The argument for `_lock` are non-trivial, having them passed explicitly makes thing clearer in my opinion. This is a Gratuitous change, I expect it will save me (and others) time in the future.

inno: remove w9xpopen.exe w9xpopen.exe is a utility program shipped with Python <3.4 (https://bugs.python.org/issue14470 tracked its removal). The program was used by subprocess to wrap invoked processes on Windows 95 and 98 or when command.com was used in order to work around a redirect bug. The workaround is only used on ancient Windows versions - versions that we shouldn't see in 2019. While Python 2.7's subprocess module still references w9xpopen.exe, not shipping it shouldn't matter unless we're running an ancient version of Windows. Python will raise an exception if w9xpopen.exe can't be found. It's highly unlikely anyone is using current Mercurial releases on these ancient Windows versions. So remove w9xpopen.exe from the Inno installer. .. bc:: The 32-bit Windows Inno installers no longer distribute w9xpopen.exe. This should only impact people running Mercurial on Windows 95, 98, or ME. Differential Revision: https://phab.mercurial-scm.org/D6068