Wed, 29 May 2019 09:56:27 -0400 tests: sort some imports that were previously missed
Augie Fackler <augie@google.com> [Wed, 29 May 2019 09:56:27 -0400] rev 42389
tests: sort some imports that were previously missed I'm a little unclear why the import checker didn't catch this before, but when I fixed it to work in Python 3 this failure started showing up. Sigh. Differential Revision: https://phab.mercurial-scm.org/D6454
Wed, 29 May 2019 09:55:35 -0400 contrib: fix import-checker to operate on str instead of bytes
Augie Fackler <augie@google.com> [Wed, 29 May 2019 09:55:35 -0400] rev 42388
contrib: fix import-checker to operate on str instead of bytes I believe this is fallout from other Python 3 cleanups, and our code linting tools are now leaning towards operating on str and not bytes. I don't feel strongly, so I've just restored this tool to working on Python 3. Differential Revision: https://phab.mercurial-scm.org/D6453
Tue, 28 May 2019 16:12:11 -0700 verify: use self._err not self.err, it changed in 7eaf4b1ac2a3
Kyle Lippincott <spectral@google.com> [Tue, 28 May 2019 16:12:11 -0700] rev 42387
verify: use self._err not self.err, it changed in 7eaf4b1ac2a3 Differential Revision: https://phab.mercurial-scm.org/D6451
Tue, 28 May 2019 23:22:46 -0700 tests: make run-tests exit non-zero if there are "errors"
Kyle Lippincott <spectral@google.com> [Tue, 28 May 2019 23:22:46 -0700] rev 42386
tests: make run-tests exit non-zero if there are "errors" Previously, if there was an error such as a broken .t file that caused run-tests.py to encounter an exception during parsing, the test would be considered in an "errored" state, which is separate from "failed". The check for whether to exit non-zero or not was based entirely on whether there were any tests in a "failed" state, so if there was only an error, run-tests would exit with 0. Our test infrastructure would then consider the test as passing, causing us to have some tests with false negatives that have gone undetected for a few weeks now. Differential Revision: https://phab.mercurial-scm.org/D6452
Thu, 23 May 2019 18:15:08 +0200 perf: add a `perfhelper-mergecopies` command
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 18:15:08 +0200] rev 42385
perf: add a `perfhelper-mergecopies` command This command gather data that are useful to pick argument for `perfmergecopies`.
Thu, 23 May 2019 14:48:02 +0200 perf: add a new `perfmergecopies` command
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 14:48:02 +0200] rev 42384
perf: add a new `perfmergecopies` command This command benchmark calls to `mercurial.copies.mergecopies`
Thu, 23 May 2019 14:02:01 +0200 perf: factor selection of revisions involved in the merge out
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 14:02:01 +0200] rev 42383
perf: factor selection of revisions involved in the merge out We will introduce more performance command around merge. As a first step we factor out pieces of `perfmergecalculate` that can be reused.
Thu, 23 May 2019 13:49:31 +0200 perf: allow to specify the base of the merge in perfmergecalculate
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 13:49:31 +0200] rev 42382
perf: allow to specify the base of the merge in perfmergecalculate We can now test the rebase case.
Thu, 23 May 2019 11:19:48 +0200 perf: add a --from flag to perfmergecalculate
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 11:19:48 +0200] rev 42381
perf: add a --from flag to perfmergecalculate Before this change, `perfmergecalculate` was always benchmarking the merge of the working copy with another revision. We can now benchmark the `mergecalculate` call for any arbitrary pair of revision.
Tue, 28 May 2019 09:57:53 -0400 merge with stable
Augie Fackler <augie@google.com> [Tue, 28 May 2019 09:57:53 -0400] rev 42380
merge with stable
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip