In D8633#133021, @indygreg wrote:

I need to think about the implications of this change a bit more: the requires file plays an important part in how clients open repositories and there are significant backwards and forwards compatibility concerns.
One immediate request is to document semantics in mercurial/helptext/internals/requirements.txt as part of this change.

In D8633#133201, @pulkit wrote:

In D8633#133117, @indygreg wrote:

I left a handful of comments.
Changing repo opening semantics and requirements handling is a bit scary.
I'm generally in favor of separating working directory requirements from non-working directory requirements so I think this patch is a step in the right direction. There are a few alternative implementations worth considering. (Although I'm unsure if they are superior.)

1. Write the new requirements file in the .hg directory as .hg/store-requires (or similar). Conceptually, we're talking about working directory and backend requirements. The "store" is just today's layout for storing backend data [which can be shared between working directories].
2. Write a new requirements file for working directory specific requirements.

Hi, thanks a lot for the detailed review. I think we can have .hg/requires as working directory specific and .hg/store/requires as store requirements.
I have not yet implemented all the fixes you mentioned. Hence marking this as planned changes. However I have added some parents patches which should be good to review.

In D8923#133565, @marmoute wrote:

This seems to conflict with my request for D8921, do we have a good way forward that allow to still rename the key ?

In D8921#133559, @marmoute wrote:

Having a filenode key that does not contains a filenode is quite misleading. Can we use a different key ? (and align the extrastate dict in the same direction?)

This seems to conflict with my request for D8921, do we have a good way forward that allow to still rename the key ?

Having a filenode key that does not contains a filenode is quite misleading. Can we use a different key ? (and align the extrastate dict in the same direction?)

Good work tracking down this obscure failure!

A similar patch already landed. I'm going to commandeer and close.

I'm not sure what the README.rst rename was doing in the diff. So I dropped it in-flight.

Debian's perturbations to how Python is packaged continue to confound me. There's aren't enough Picard facepalm memes to express my feelings on the matter.