There is a lot of duplication here. Can you try to extract common parts?

In D6612#97313, @durin42 wrote:

(Martin, this looks fine to me, if you've got no objections let's include it in 5.1)

In D6641#97205, @yuja wrote:

• a/mercurial/__init__.py

+++ b/mercurial/__init__.py
@@ -225,7 +225,9 @@

• 1. It changes iteritems/values to items/values as they are not
  2. present in Python 3 world.
• elif fn in ('iteritems', 'itervalues'):

+ elif (fn in ('iteritems', 'itervalues') and
+ not (tokens[i - 1].type == token.NAME and
+ tokens[i - 1].string == 'def')):

Perhaps, we need to bump the BYTECODEHEADER version to recompile all
py3 modules.

See some thoughts from me and others on https://bz.mercurial-scm.org/show_bug.cgi?id=4292. Is your goal to shrink the changelog? Or that you feel that the current behavior is incorrect? Or something else?

Wow, Phabricator decides to send the email almost two full days after the
review was created. Anyone knows what's going on?

In D6430#96225, @marmoute wrote:

The ×2.5 speedup is the kind of things that motivate this series. Even if the mozilla-unified/mozilla-try is just and example it triggers the kind of pathological case we encounter in real life: large undecided set. We keep finding such pathological case from time to time, and will keep finding them. In addition there are case with legitimate large undedicated set (the mozilla example for one).
Having this faster code significantly reduce the impact of these pathological cases.

Thanks for fixing this quickly! The fix looks very straight-forward too.

In D6475#95878, @martinvonz wrote:

Try this:
hg co -C 4.9; hg debugrebuilddirstate; hg co 5.0; hg st
Before this patch, that produced an empty output as it should. After this patch, it lists hundreds of modified files (536 to be specific). A workaround is to add --config worker.enabled=no. Can you look into it? It's obviously a pretty serious bug that needs to be fixed before we release a new version.

Try this:

In D6561#95834, @yuja wrote:

while work:

• r, i1, copies1 = heapq.heappop(work)

+ r, i1, copies = heapq.heappop(work)

if work and work[0][0] == r:
    # We are tracing copies from both parents
    r, i2, copies2 = heapq.heappop(work)

• copies = {}
• allcopies = set(copies1) | set(copies2)
• for dst in allcopies:

+ for dst, src in copies2.items():

• 1. Unlike when copies are stored in the filelog, we consider
  2. it a copy even if the destination already existed on the
  3. other branch. It's simply too expensive to check if the
  4. file existed in the manifest.
• if dst in copies1:
• # If it was copied on the p1 side, mark it as copied from

+ if dst not in copies:
+ # If it was copied on the p1 side, leave it as copied from

• 1. that side, even if it was also copied on the p2 side.
• copies[dst] = copies1[dst]
• else: copies[dst] = copies2[dst]

Are we sure there's no copies alias held by later work?
I'm just asking because we've optimized some copies.copy()s away at
5ceb91136ebe. I don't know if it's safe or not to mutate copies at this
point.

Need to set the parent of this patch