upgrade: use the repository 'ui' as the base for the new repository The `repo.baseui` contains all the configuration but the one specific to the repository (so it can be used when dealing with local peer and sub- repository). However, we need the repository config to be taken into account when doing the upgrade. Otherwise, the upgrade related config that exists in the repository config won't be taken into account when performing the update. A buggy and surprising behavior. We had to work around protection set around `repo.ui.copy` since we are an uncommon case.

upgrade: add a test to show the repository config being ignored The upgrade process ignores the config within the repository. The next changeset fixes it, but we introduce this test before to show it actually tests our target.

upgrade: register compression as a format variants Compression is a promising vector for speedup, let us make it easier to check the compression used and upgrade existing repository.

debugformat: handle non-boolean value for variant

debugformat: update label depending on value difference The new label highlight areas where the repo format differs from current config or default. This should help people spot area where a repository mismatch with the expected state.

debugformat: add data about the config when verbose In verbose mode, the command also displays the current configuration choice for the variant and the global Mercurial default for it.

debugformat: add a 'debugformat' command The command displays basic data about all format variants registered for repo upgrades. This gives a quick way to peek into a repository format. The 'fm.write()' calls are very independent because more data will be added in later changeset. Having more separate call make the later patch clearer.

upgrade: rename 'removecldeltachain' to 'plain-cl-delta' The new naming is more descriptive of a "state" while the older one was more about "action". I'm looking into command exposing more of data about the state of the repository so "state" oriented work better there. The key has not been made public anywhere outside the debug area so it is fine to update it.

tests: glob away ' that doesn't occur on all platforms in lfs test Differential Revision: https://phab.mercurial-scm.org/D1623

rebase: extract _assignworkingcopy Slightly cleaner, and makes it easier to hook this in an extension. Differential Revision: https://phab.mercurial-scm.org/D1617

rebase: disable `inmemory` if the rebaseset contains the working copy As described in the comment, rebasing the working copy parent with in-memory merge, and then updating to the new commit, isn't much faster because of the extra overhead of uppdating. Best to leave it off in that case. This commit makes deploying in-memory merge via an extension easier, because you can just set `inmemory=True` based on some config or probability, and this will turn off the cases where it's not desired. Differential Revision: https://phab.mercurial-scm.org/D1616

clone: add support for storing remotenames while cloning If `experimental.remotenames` is set to True, we store the remotenames in case of `hg pull`. This patch adds that support to clone command also. Differential Revision: https://phab.mercurial-scm.org/D1601

revset: use phasecache.getrevset to calculate public() Other revsets like secret(), draft(), _nonpublic() are using phasescache.getrevset already. The latter is more efficient after D1606. So let's migrate the public() revset function too. Tested using: $ hg debugshell --hidden --cwd hg-committed` In [1]: %timeit len(repo.revs('public()')) * Before D1606: 10 loops, best of 3: 22.5 ms per loop * Before this change, after D1606: 10 loops, best of 3: 28.6 ms per loop * After this change: 10 loops, best of 3: 20.2 ms per loop Therefore `public()` revset becomes even slightly faster after the data structure change by D1606. A similar performance win could also be observed on a large repo. A side effect is `phasecache.getrevset` needs to take a `subset` parameter. That was added with a default value so it won't cause BC issues. Differential Revision: https://phab.mercurial-scm.org/D1620

highlight: eagerly discover plugin lexers while demandimport is off Since highlight is only relevant for servers, it seems worthwhile to just trigger this eagerly, which avoids really weird traceback problems caused by demandimport messing with some of the lexer plugins. Differential Revision: https://phab.mercurial-scm.org/D1619