The test case fails on both py2 and py3 for me. This CI pipeline agrees that it's failing: https://foss.heptapod.net/octobus/mercurial-devel/-/pipelines/11695. Can you send a fix?

I'm happy to let the wait until @marmoute has no more pending patches.

In D9173#138276, @pulkit wrote:

In D9173#138239, @marmoute wrote:

In D9173#138235, @martinvonz wrote:

In D9173#138208, @marmoute wrote:

This adds a non negligible amount of churn that conflict with an import bug series I submitted (See D9195 and above).
Can we drop it for now and restart review on a new diff?

That was sent for review after this series, so I don't think it's fair to drop this one for that reason.

You probably noticed that I have been sending a pretty regular stream of patch on this topic over the last month. This series is just the continuation of this. I would have appreciated if you would have coordinated with me before starting sending arbitrary patch on this topic. The lack of communication is probably going to cost too many hours for both of us.

In particular, I do not understand why the changeset version of the algorithm is not giving use the same result as the compatibility one.

I think I explained that in the commit message: hg log --follow <file> doesn't work with copy information (only) in the changelog, since it has a fast-path that follows the revisions in the filelog. We (probably I) will need to fix that some day...

We should probably explicitly add this information around the if block.

Yes, it will be nice to get this documented around that block.

In D9167#138287, @pulkit wrote:

In D9167#138132, @martinvonz wrote:

I've renamed the exception to InputError to unblock this. Let me know if there was anything else blocking. I wasn't sure if you wanted to see more discussion about the name on thread before we decide.

Thank you. I am thinking to get back to this (queue this maybe) once we cut the upcoming RC (after 3 days). I agree that there are no BC changes but doing this will make things easier as then we can try to have all these changes in one release. Doesn't yield much but sounds like a good idea to me. Let me know if you prefer it to be queued before.

In D9173#138208, @marmoute wrote:

This adds a non negligible amount of churn that conflict with an import bug series I submitted (See D9195 and above).
Can we drop it for now and restart review on a new diff?

In D9171#138205, @marmoute wrote:

This test case should go in tests/test-copies-chain-merge.t since this is where the combination of merging and copies information is tested.

I really don't like this patch. I did the split back in D8377 because I found this format very hard to read. IIRC, at least @pulkit agreed with me. I don't understand why testing of upgrades require this structure.

I've renamed the exception to InputError to unblock this. Let me know if there was anything else blocking. I wasn't sure if you wanted to see more discussion about the name on thread before we decide.

Feel free to fold this into D9179 or add on top

Reviewers: Up to here is ready for review (and uncontroversial, I would think)

In D9159#137749, @martinvonz wrote:

In D9159#137729, @marmoute wrote:

Regardless of the issue6163 question, simply dropping the tracking or removed files seems wrong and will introduces bug (eg: we can end up merging a "dead" file history with a fresh file history, picking the "dead" one). So we cannot do that.
minimal description of the case I am talking about below.

o → X should be copied from B, not A
| \
o |  delete X 
| |
o |  rename A to X
| |
| o rename B to X
|/
o

I added that test as a parent of this patch (D9171). It passed before and after this patch. Did I not write it down correctly?

I'm breaking the rules by queuing this myself so we can have tests passing again

In D9159#137869, @marmoute wrote:

My previous, larger comment got lost. It contained other tests cases.
I do not have time re-type my full comment (phabricator eating comment is very upsetting).