Seems obviously correct to me. I'll queue this for stable. @indygreg can tell me if I'm wrong.

That seems to fix the failing test on both py2 and py3. Thanks!

In D9152#138736, @martinvonz wrote:

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?

Actually, let me insert a patch before this one that adds the config that gives us more detailed exit codes. That way we can see the impact on tests in this patch.

Thanks! Sorry I missed this patch earlier.

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)