Summary:
`push --new-branch` is very rarely used and it does not make much sense with
checkheads removed (D14179861). Remove it everywhere.
There is still [one user](https://fburl.com/t5hmcxrp) of the
`push --new-branch` flag. Do not remove it just yet.
Reviewed By: singhsrb
Differential Revision: D14212180
fbshipit-source-id: 18f80576ab6464fc36b047a8a35b339231ee9d8e
Summary: Mostly empty lines removed and added. A few bugfixes on excessive line splitting.
Reviewed By: quark-zju
Differential Revision: D8199128
fbshipit-source-id: 90c1616061bfd7cfbba0b75f03f89683340374d5
Summary:
Turned on the auto formatter. Ran `arc lint --apply-patches --take BLACK **/*.py`.
Then run `arc lint` again so some other autofixers like spellchecker etc. looked
at the code base. Manually accept the changes whenever they make sense, or use
a workaround (ex. changing "dict()" to "dict constructor") where autofix is false
positive. Disabled linters on files that are hard (i18n/polib.py) to fix, or less
interesting to fix (hgsubversion tests), or cannot be fixed without breaking
OSS build (FBPYTHON4).
Conflicted linters (test-check-module-imports.t, part of test-check-code.t,
test-check-pyflakes.t) are removed or disabled.
Duplicated linters (test-check-pyflakes.t, test-check-pylint.t) are removed.
An issue of the auto-formatter is lines are no longer guarnateed to be <= 80
chars. But that seems less important comparing with the benefit auto-formatter
provides.
As we're here, also remove test-check-py3-compat.t, as it is currently broken
if `PYTHON3=/bin/python3` is set.
Reviewed By: wez, phillco, simpkins, pkaush, singhsrb
Differential Revision: D8173629
fbshipit-source-id: 90e248ae0c5e6eaadbe25520a6ee42d32005621b
test-verify-repo-operations.py currently starts way too late and
extends the running time with -j50 on my machine from around 3:48 min
to 6:30 min. We could of course make it run earlier, but the test case
seems unlikely to find bugs not covered by other tests, so let's mark
it "slow" instead. I think this type of test is better suited to
running separately in a long-running job.
Doing this required the introduction of a mechanism for keeping
track of more general config in the test. At present this is only
used for extensions but it could be used more widely (e.g. to
control specific extension behaviour)
This greatly simplifies the extension management logic by introducing
a general notion of config, which we maintain ourselves and pass to
HG on every invocation.
This results in significantly less error prone test generation, and
also allows us to turn extensions off as well as on.
The logic that used an environment variable to rerun the tests with
an extension disabled now just edits the test file (in a fresh copy)
to remove these --config command line flags.
This gives a good way of letting Hypothesis run until it
finds an error, save that error, and be restarted without it
picking up on the old bug. This lets you run long-running
Hypothesis processes and then perform a manual deduplication
task on the bugs found at the end.
It's not an entirely satisfying way of using this, but anything
much better would require extensive changes to Hypothesis itself.
This adds support for testing extensions, including both tests
that extensions don't change behaviour and test for specific
commands.
We use the precondition system to determine what commands are
available to us. If we never use any commands enabled by an
extension then that extension is *skippable* and should not
have changed the behaviour of the test. We thus rerun the test
with an environment variable which is designed to turn off the
extension.
This expands the Hypothesis based stateful testing so that
rather than having a single repository under test, Hypothesis
manages a family of repositories. Some of these are freshly
created, some are clones of others.
The idea of this patch is to expand the use of Hypothesis
within Mercurial to use its concept of "stateful testing".
The result is a test which runs a sequence of operations
against a Mercurial repository. Each operation is given a
set of allowed ways it can fail. Any other non-zero exit
code is a test failure.
At the end, the whole sequence is then reverified by
generating a .t test and testing it again in pure
mode (this is also useful for catching non-determinism
bugs).
This has proven reasonably effective at finding bugs,
and has identified two problems in the shelve extension
already (issue5113 and issue5112).
