Looks like these changes were absorbed into 8fcc0a82, so this is unnecessary now.

In D10538#160300, @joerg.sonnenberger wrote:

I'm not sure that this is an improvement. We discussed whether we want to hard-wire the version even stricter ("exactly version 11"), especially because it is hard to predict when the output is going to change again.

In D10470#160272, @Alphare wrote:

This breaks the CI https://foss.heptapod.net/octobus/mercurial-devel/-/pipelines/21383.
Could you send a followup please?

I thought I'd run the entire test suite and it passed before sending. Sorry about that! Fixed fncache and inherit-mode by not writing out the narrowspec backup in the mkstemp call. I'm not getting any failures in test-check-code.t, can you share what ones you're seeing?

(marking comment as resolved, not sure what the exact policy is here :))

In D9952#159267, @marmoute wrote:

@spectral, What is the range of code you want to ensure a race with ? and how is the synchronization happening to reach it ?

I'm unable to reproduce. I've run the test over 10,000 times (I added a #testcases a b c d e f g h i j k l m n o p q r s t u v w x y z so it ran 26 times each run, and I've run over 300 instances of that like run-tests.py -j26 -l --chg test-racy-mutations.t, over 100 with -j108, and other combinations (with and without the added testcases, with and without --chg, etc.)

I'm apparently not going to resolve the comments, sorry for leaving this open so long.

In D10386#158301, @pulkit wrote:

Fails to apply cleanly on current tip of default branch. Kindly rebase and resend.

Sorry, I'm not super familiar with the phabricator workflow, should I be doing something more here?

Adding yuja as an explicit reviewer.

In D9952#150755, @joerg.sonnenberger wrote:

This still adds all of the function call overhead even when the feature is not used. I also don't like that this check is done repeatedly e.g. during an unbundle. I don't think I would mind checking the size once per revlog on the first write, but not repeatedly.

Seems fine. ACTIVATE_SH is still in there on the version I have on my Debian Testing machine (15.1.0+ds-3 according to the dpkg system, 15.1.0 according to virtualenv.version). Not sure when it was removed, but it's not really relevant. :)