evolve: abort if deciding resolution parent is ambiguous While solving content-divergence, it could be hard to decide which cset should be treated as a resolution parent if there are multiple successors of divergent cset. i.e split case. But we are planning to make some update in handling this split case: 1) consider highest one if all splitted csets are in a single topological branch 2) still need to decide if 1) doesn't apply

evolve: make sure divergence resolution doesn't undo changes (issue6203) Before this patch, in content-divergence resolution logic if resolution parent is not the parent of any of the two divergent changesets then it could undo some changes introduced by previous revs (while resolving stack of content-divergent changesets) as demonstrated by the test added in previous patch. To solve this, what this patch doing is: if divergent cset has obsolete parent with a successor then first resolve the "orphan" instability of divergent cset by relocating, then perform the content-divergence resolution. After this change in logic, I found that it's kind of more correct as reflected by the changes in tests/test-evolve-content-divergent-corner-cases.t where it prevented creating conflicts while merging. Changes in tests/test-evolve-content-divergent-stack.t demonstrate the fixed behaviour. Next patches will be covering the `evolve --continue` case for the relocation of "divergent" cset.

evolve: add test to demonstrate issue6203 Current logic of content-divergence resolution contains a bug that if resolution parent is not the parent of any of the two divergent changesets, it could undo some changes. I think a good solution for this is to first relocate the divergent cset to it's obsolete parent's successor if applicable and then perform the content-divergence resolution. Next patch will fix the issue.

state: there's no _unpack in struct Caught by pytype.

amend: abort if both --patch and --extract are used

test-compat: merge mercurial-4.6 into mercurial-4.5