tests: use the system hg for examining the local repository Most test scripts use "hg" to interact with a temporary test repository. However a few tests also want to run hg commands to interact with the local repository containing the mercurial source code. Notably, many of the test-check-* tests want to check local files and commit messages. These tests were previously using the version of hg being tested to query the source repository. However, this will fail if the source repository requires extensions or other settings not supported by the version of mercurial being tested. The source repository was typically initially cloned using the system hg installation, so we should use the system hg installation to query it. There was already a helpers-testrepo.sh script designed to help cope with different requirements for the source repository versus the test repositories. However, it only handled the evolve extension. This new behavior works with any extensions that are different between the system installation and the test installation.

tests: save the original PATH and PYTHONPATH variables When running the tests, define ORIG_PATH and ORIG_PYTHONPATH environment variables that contain the original contents of PATH and PYTHONPATH, before they were modified by run-tests.py This will make it possible for tests to refer to the original contents of these variables if necessary. In particular, this is necessary for invoking the correct version of hg for examining the local repository (the mercurial repository itself, not the temporary test repositories). Various tests examine the local repository to check the file lists and contents of commit messages.

setup: prefer using the system hg to interact with the local repository Add a findhg() function that tries to be smarter about figuring out how to run hg for examining the local repository. It first tries running "hg" from the user's PATH, with the default HGRCPATH settings intact, but with HGPLAIN enabled. This will generally use the same version of mercurial and the same settings used to originally clone the repository, and should have a higher chance of working successfully than trying to run the hg script from the local repository. If that fails findhg() falls back to the existing behavior of running the local hg script.

setup: replace runhg() with an hgcommand helper class Replace the runhg() function with an hgcommand helper class. hgcommand has as run() function similar to runhg(), but no longer requires the caller to pass in the exact path to python and the hg script, and the environment settings for invoking hg. For now this diff contains no behavior changes, but in the future this will make it easier for the hgcommand helper class to more intelligently figure out the proper way to invoke hg.

setup: move environment computation into a helper function Add a helper function to compute the environment used for invoking mercurial, rather than doing this computation entirely at global scope. This will make it easier to do some subsequent refactoring.

setup: update runcmd() to also return the exit status Update the runcmd() helper function so it also returns the process exit status. This allows callers to more definitively determine if a command failed, rather than testing only for the presence of data on stderr. I don't expect this to have any behavioral changes for now: the commands invoked by setup generally should print data on stderr if and only if they failed.

setup: fail if we cannot determine the version number If running hg fails, exit the setup script unsuccessfully, rather than proceeding to use a bogus version of "+0-". Using an invalid version number causes various tests to fail later. Failing early makes it easier to identify the source of the problem. It is currently easy for setup.py to fail this way since it sets HGRCPTH to the empty string before running "hg", which may often disable extensions necessary to interact with the local repository.

smartset: fix generatorset.last() to not return the first element (issue5609)

strip: respect the backup option in stripcallback The backup option was mistakenly ignored. It should be respected. Thanks Martin von Zweigbergk for finding this out!

py3: use pycompat.bytestr() to convert str to bytes

py3: pass the memoryview object into bytes() to get the value

py3: use pycompat.bytestr instead of str

py3: use '%d' to convert integers to bytes

py3: slice over bytes to prevent getting it's ascii value

py3: use pycompat.strkwargs() to convert kwargs keys to str

py3: use r'' to prevent the addition of b'' by transformer There are cases in opts handling in debugcommands.py where we don't need to convert opts keys back to bytes as there are some handful cases and no other function using opts value. Using r'', we prevent the transformer to add a b'' which will keep the value str.

py3: use pycompat.byteskwargs() to convert kwargs' keys to bytes This is used where ever required like where kwargs are passed into ui.formatter(), scmutil.match() or cmdutil.openrevlog() which expects bytes.

tests: use cgienv to minimize environment setup at hgweb tests This patch follows other hgweb tests.

tests: avoid test failure for mangling path-like string by MSYS

py3: make sure commands name are bytes in tests

py3: add b'' to make the regex pattern bytes

py3: use hex() to convert the hash to bytes

py3: add b'' to make a triple quoted string bytes on Python 3 Transformer does not adds b'' in front of triple quoted strings to prevent converting docs to bytes.

py3: add tests to show `hg bookmarks` and `hg branches` work on Python 3

py3: fix kwargs handling for `hg bookmarks`

identify: provide changectx to templater

formatter: proxy fm.context() through converter Otherwise nested template formatter would not see the context objects. It's just a boolean flag now. We might want to change it to 'ctxs -> items' function so changectx attributes are populated automatically in JSON, but I'm not sure.

identify: change p1/p2 to a list of parents It makes sense because the nested data structure is a list of items.

scmutil: add a cleanupnodes method for developers It's now common that an old node gets replaced by zero or more new nodes, that could happen with amend, rebase, histedit, etc. And it's a common requirement to do bookmark movements, strip or obsolete nodes and even moving working copy parent. Previously, amend, rebase, history have their own logic doing the above. This patch is an attempt to unify them and future code. This enables new developers to be able to do "replace X with Y" thing correctly, without any knowledge about bookmarks, strip or obsstore. The next step will be migrating rebase to the new API, so it works inside a transaction, and its code could be simplified.

strip: add a delayedstrip method that works in a transaction For long, the fact that strip does not work inside a transaction and some code has to work with both obsstore and fallback to strip lead to duplicated code like: with repo.transaction(): .... if obsstore: obsstore.createmarkers(...) if not obsstore: repair.strip(...) Things get more complex when you want to call something which may call strip under the hood. Like you cannot simply write: with repo.transaction(): .... rebasemod.rebase(...) # may call "strip", so this doesn't work But you do want rebase to run inside a same transaction if possible, so the code may look like: with repo.transaction(): .... if obsstore: rebasemod.rebase(...) obsstore.createmarkers(...) if not obsstore: rebasemod.rebase(...) repair.strip(...) That's ugly and error-prone. Ideally it's possible to just write: with repo.transaction(): rebasemod.rebase(...) saferemovenodes(...) This patch is the first step towards that. It adds a "delayedstrip" method to repair.py which maintains a postclose callback in the transaction object.