Looks good

That seems fine to me. We can battle with rustc to re-introducing the genericity when we actually need it.

I wanted the obsmarker. Which was not created (then my comment was wrong).

ha, okay

The logic looks good, but I hve a minor point on about the test.

tests/test-install.t and tests/test-duplicateoptions.py are unhappy about this change.

Thanks (but apparently you did created an obsmarker)

This looks fine

Now that a fix as landed in python 3.9 should we back this out ?

@Alphare gentle ping to provide a todo list here.

The behavior and the code looks good to me. I guess we should document the variable and the behavior somewhere. However I am not sure of where that might be. @yuya do you know where the chg documentation lives ?

In D8937#134836, @Alphare wrote:

Thanks for taking the time to do this.
I however still have reservations as to adding MacOS as a supported platform since it currently is tested in no CI that runs even semi-frequently on Rust code.
Also, what do you mean by "most tests pass"? What is needed to make the rest pass? And finally, which is the correct behavior from the Python version or the Rust one (according to your new commit message)?
I will take time to take a look at the code in detail after this becomes clearer for me, just so I can understand what compromise, if any, you're making right now.

Did you measure the performance impact on other operation than your target operation ? I am curious about the impact of the @property here.

In D8977#135146, @pulkit wrote:

In D8977#135054, @marmoute wrote:

Why don't we get a test change with this ?

The test changes are visible after disabling the m2-vs-ma optimization. I just plugged it before to minimize the test changes in that patch which disables the optimization.

looks good. As an unrelated change, maybe add a comment on the previous block to indicate it is relevant for all python starting from 3.9+

(maybe update the description to state this since this is a common question)

Sounds good then :-)

great

sounds good.

Does this affect all merge (especially hg merge) ? or just the one where the working copy has only one parent?

looks good

This kind of massive code block move in a huge function make me think we should slice it into smaller function. What do you think?

Why don't we get a test change with this ?

♥

Thanks for the update.

not great, but okay.

♥

(I wonder if we don't use "missing" more than "absent" through the code. However quick grepping is not very conclusive and "missing" could be confused with the hg status state)

Cf feedback on the previous changeset about the semantic of the message.

Looks good.

Looks good. Out of curiosity, did you do any performance measurement of this?

So right now the bid merge still behave in a bad way (delete the file instead of conflicting, but at least not it consistently does so regardless of where the merge is started?

thanks for the extensive documentation.

Seems saner

big +1

This looks fine.

Should we move this to change requested since this is WIP ?

(updating status to reflect the current discussion status)

The approach used by the nodemap is probably a good way forward for transactional case. Some kind of happen only index, that get recompacked on a regular basis. Combined with an append only data file (for example, children can be stored as linked list (data file size) with a pointer to the first entry in an index file.

Looks good.