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
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`.
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`
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.
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.
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.
Augie Fackler <augie@google.com> [Tue, 28 May 2019 09:57:53 -0400] rev 42380
merge with stable
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 25 May 2019 19:49:44 +0300] rev 42379
py3: fix test-narrow* which started failing because of recent changes
#skip-blame because just r'' prefix
Differential Revision: https://phab.mercurial-scm.org/D6447
Matt Harbison <matt_harbison@yahoo.com> [Thu, 23 May 2019 22:50:11 -0400] rev 42378
manifest: add some documentation to _lazymanifest python code
It was not particularly easy figuring out the design of this class and keeping
track of how the pieces work. So might as well write some of it down for the
next person.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 23 May 2019 21:54:24 -0400] rev 42377
manifest: avoid corruption by dropping removed files with pure (issue5801)
Previously, removed files would simply be marked by overwriting the first byte
with NUL and dropping their entry in `self.position`. But no effort was made to
ignore them when compacting the dictionary into text form. This allowed them to
slip into the manifest revision, since the code seems to be trying to minimize
the string operations by copying as large a chunk as possible. As part of this,
compact() walks the existing text based on entries in the `positions` list, and
consumed everything up to the next position entry. This typically resulted in
a ValueError complaining about unsorted manifest entries.
Sometimes it seems that files do get dropped in large repos- it seems to
correspond to there being a new entry that would take the same slot. A much
more trivial problem is that if the only changes were removals, `_compact()`
didn't even run because `__delitem__` doesn't add anything to `self.extradata`.
Now there's an explicit variable to flag this, both to allow `_compact()` to
run, and to avoid searching the manifest in cases where there are no removals.
In practice, this behavior was mostly obscured by the check in fastdelta() which
takes a different path that explicitly drops removed files if there are fewer
than 1000 changes. However, timeless has a repo where after rebasing tens of
commits, a totally different path[1] is taken that bypasses the change count
check and hits this problem.
[1] https://www.mercurial-scm.org/repo/hg/file/2338bdea4474/mercurial/manifest.py#l1511