Martin von Zweigbergk <martinvonz@google.com> [Sun, 14 Apr 2019 00:46:25 -0700] rev 42163
merge: remove workaround for
issue5020
As I explained in the previous commit, I think the filtering added
there is a better fix for the issue, so the workaround from
41f6af50c0d8 (merge: fix crash on criss cross merge with dir move and
delete (
issue5020), 2017-01-31) should no longer be needed.
Differential Revision: https://phab.mercurial-scm.org/D6245
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Apr 2019 22:03:04 -0700] rev 42162
copies: don't include copies that are not in source in directory move
I've been working on a rewrite of mergecopies(). I compared the output
of the rewritten version with the current version. I noticed that
between FIREFOX_NIGHTLY_59_END and FIREFOX_BETA_60_BASE in the
mozilla-unified repo, there were many copies that the current version
detected that the rewritten version did not. One example was
js/src/gc/Iteration.h -> js/src/gc/PublicIterators.h. Then I realized
that js/src/gc/Iteration.h doesn't even exist in
FIREFOX_NIGHTLY_59_END.
This patch adds a filtering step for the "fullcopy" dict. It turns out
that that change also affects the test for
issue5020 in
test-merge-criss-cross.t. The 'dm' action no longer happens there. At
first I thought that the test case change meant that this patch was
broken, but I think it's actually correct tha the 'dm' action should
not happen there. The result of the bid merge is still the same.
I suspect this filtering is a better solution for the issue than
41f6af50c0d8 (merge: fix crash on criss cross merge with dir move and
delete (
issue5020), 2017-01-31). I also suspect that it was broken
just a few months earlier by
a005c33d0bd7 (mergecopies: add logic to
process incomplete data, 2016-10-04). Note that bid merge had been
enabled for a few years at that point, since
19903277f035 (merge: use
bid merge by default (BC), 2014-10-01).
This patch is still just a workaround. It will be cleaned up soon
(with the rewrite of mergecopies()). But doing this in a separate
patch makes later patches easier to understand and gives a place to
explain why this is changing.
Differential Revision: https://phab.mercurial-scm.org/D6244
Martin von Zweigbergk <martinvonz@google.com> [Sat, 13 Apr 2019 00:24:17 -0700] rev 42161
tests: add test for
issue5343 (grafting with copies)
It seems that
issue5353 resulted in a lot of tests in test-graft.t,
but the bug actually reported in that issue didn't get a test
case. This patch adds one for the "move" and one for the "copy"
version of it. I also added a "copy+modify" case, to show what should
be a merge conflict. I didn't add one for the "backwards" version of
it since the comment says that that was already covered by previous
work.
The tests added by this patch show the broken behavior (the bug is
still open). I suspect the results returned from mergecopies() are not
expressive enough to fix this issue: it has a dict for copies to merge
with, but that can only give one more filename, but here we need two
(one for the path on the remote side and one for the path in the merge
base). I want to have it tested anyway since I'm about to refactor
mergecopies().
Differential Revision: https://phab.mercurial-scm.org/D6242
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Tue, 16 Apr 2019 13:12:21 -0400] rev 42160
chistedit: use context manager to set verbose ui
I'm still not exactly sure why this is necessary -- perhaps setting it
unconditionally would leak this setting in chg invocations.
Regardless, this would have looked very out of place as compared to
how this setting is done everywhere else, so at least for the sake of
style, let's be consistent with the rest of the codebase.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 Apr 2019 17:26:38 +0200] rev 42159
setdiscovery: stop limiting the number of local head we initially send
In our testing this limitation provides now real gain and instead triggers
pathological discovery timing for some repository with many heads.
See inline documentation for details.
Some timing below:
Mozilla try repository, (~1M revs, ~35K heads), discovery between 2 clones with
100 head missing on each side
before:
! wall 1.492111 comb 1.490000 user 1.450000 sys 0.040000 (best of 20)
! wall 1.813992 comb 1.820000 user 1.700000 sys 0.120000 (max of 20)
! wall 1.574326 comb 1.573500 user 1.522000 sys 0.051500 (avg of 20)
! wall 1.572583 comb 1.570000 user 1.520000 sys 0.050000 (median of 20)
after:
! wall 1.147834 comb 1.150000 user 1.090000 sys 0.060000 (best of 20)
! wall 1.449144 comb 1.450000 user 1.330000 sys 0.120000 (max of 20)
! wall 1.204618 comb 1.202500 user 1.146500 sys 0.056000 (avg of 20)
! wall 1.194407 comb 1.190000 user 1.140000 sys 0.050000 (median of 20)
pypy (~100 heads, 317 heads) discovery between clones with only 42 common heads
before:
! wall 0.031653 comb 0.030000 user 0.030000 sys 0.000000 (best of 25)
! wall 0.055719 comb 0.050000 user 0.040000 sys 0.010000 (max of 25)
! wall 0.038939 comb 0.039600 user 0.038400 sys 0.001200 (avg of 25)
! wall 0.038660 comb 0.050000 user 0.040000 sys 0.010000 (median of 25)
after:
! wall 0.018754 comb 0.020000 user 0.020000 sys 0.000000 (best of 49)
! wall 0.034505 comb 0.040000 user 0.030000 sys 0.010000 (max of 49)
! wall 0.019631 comb 0.019796 user 0.018367 sys 0.001429 (avg of 49)
! wall 0.019132 comb 0.020000 user 0.020000 sys 0.000000 (median of 49)
Private repository (~1M revs, ~3K heads), discovery from a strip subset, about
100 changesets to be pulled.
before:
! wall 1.837729 comb 1.840000 user 1.790000 sys 0.050000 (best of 20)
! wall 2.203468 comb 2.200000 user 2.100000 sys 0.100000 (max of 20)
! wall 2.049355 comb 2.048500 user 2.002500 sys 0.046000 (avg of 20)
! wall 2.035315 comb 2.040000 user 2.000000 sys 0.040000 (median of 20)
after:
! wall 0.136598 comb 0.130000 user 0.110000 sys 0.020000 (best of 20)
! wall 0.330519 comb 0.330000 user 0.260000 sys 0.070000 (max of 20)
! wall 0.157254 comb 0.155500 user 0.123000 sys 0.032500 (avg of 20)
! wall 0.149870 comb 0.140000 user 0.110000 sys 0.030000 (median of 20)
Same private repo, discovery between two clone with 500 different heads on each
side:
before:
! wall 2.372919 comb 2.370000 user 2.320000 sys 0.050000 (best of 20)
! wall 2.622422 comb 2.610000 user 2.510000 sys 0.100000 (max of 20)
! wall 2.450135 comb 2.450000 user 2.402000 sys 0.048000 (avg of 20)
! wall 2.443896 comb 2.450000 user 2.410000 sys 0.040000 (median of 20)
after:
! wall 0.625497 comb 0.620000 user 0.570000 sys 0.050000 (best of 20)
! wall 0.834723 comb 0.820000 user 0.730000 sys 0.090000 (max of 20)
! wall 0.675725 comb 0.675500 user 0.628000 sys 0.047500 (avg of 20)
! wall 0.671614 comb 0.680000 user 0.640000 sys 0.040000 (median of 20)
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 Apr 2019 17:56:30 +0200] rev 42158
peer: introduce a limitedarguments attributes
When set to True, it signal that the peer cannot receive too larges arguments
and that algorithm must adapt. This should only be True for http peer that does
not support argument passed as "post".
This will be useful to unlock better discovery performance in the next
changesets.
I am using a dedicated argument because this is not really a usual
"capabilities" things. An alternative approach would be to adds a
"large-arguments" to all peer, but the http peers. That seemed a bit too hacky
to me.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2019 15:06:53 +0100] rev 42157
verify: also check full manifest validity during verify runs
Before this changes, `hg verify` only checked if a manifest revision existed and
referenced the proper files. However it never checked the manifest revision
content itself.
Mercurial is expecting manifest entries to be sorted and will crash otherwise.
Since `hg verify` did not attempted a full restoration of manifest entry, it
could ignore this kind of corruption.
This new check significantly increases the cost of a `hg verify` run. This
especially affects large repository not using `sparse-revlog`. For now, this is
hidden behind the `--full` experimental flag.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 Apr 2019 01:11:09 +0200] rev 42156
verify: introduce an experimental --full flag
The flag currently has no effect, see next changeset for details. We introduce
the flag as experimental to keep the freedom of changing our mind on the final
UI.
Note: this patch highlight a small but in `hg help`. An option section is
generated even if no option are visible.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 Apr 2019 01:12:21 +0200] rev 42155
verify: introduce a notion of "level"
Some checks are slower than others, to help the user to run the checks he needs,
we are about to introduce new flag to select faster vs deeper runs. This put
the scaffolding in place to do this.
Martin von Zweigbergk <martinvonz@google.com> [Sat, 13 Apr 2019 23:18:56 -0700] rev 42154
tests: split out separate test for
issue5020
The test was added to the existing setup in
41f6af50c0d8 (merge: fix
crash on criss cross merge with dir move and delete (
issue5020),
2017-01-31). I'm about to make a change that affects that test and
it's much easier to follow if the test case for
issue5020 is a
separate test case. The separate test case is based on what mpm
provided in comment 12 on the issue.
`hg diff -r
41f6af50c0d8^ tests/test-merge-criss-cross.t` after this
patch is pretty small (besides the added test). It's probably easier
for reviewers to look at that than to try to understand the diff
itself (I don't understand it).
Differential Revision: https://phab.mercurial-scm.org/D6243