In D6825#100146, @durin42 wrote:

I like where this is going, but I wonder if these specific hooks can be written without being in-process Python hooks. Reason being that Python hooks use the unstable internals of hg and are semi-discouraged if they're avoidable.

I think we should go a step further and have some built-in hooks in Mercurial itself, like we do extensions. A good first implementation would be to define those hooks somewhere where they can be imported, add tests like they are standalone hooks. As a follow-up (read: slightly more work), we can define a new config syntax for using these hooks. e.g. builtin:reject_new_heads.

I think I see where you are going with this and it seems potentially very useful.

I'm going to attempt to look at this series...

Nice catch!

This looks promising.

It sounds like we're in agreement that interfaces need to be split. Moving everything to a sub-package seems like a logical first step.

The boundary between localrepository and store is a bit murky and definitely needs some work. When I last had things paged into my brain last year, I think I was trending towards breaking up the store into discrete classes and making the code that dynamically resolves repository types cherry pick the classes depending on the opener options. But we could easily have the store handle this logic as well. This is all very complicated and I don't prescribe to have a single correct answer.

The presence of __del__ is a bit dangerous and I've debugged a handful of issues related to having __del__ on transaction. We still leak repo objects in places due to circular references. It's super annoying.

This series is for stable. (I forgot Phabricator didn't handle branch names well.)

I'm also not super crazy about abusing extras for this. But it is the best compromise considering the "better" solutions require a lot more effort and thought. At some point, I would like Mercurial's storage and wire protocol to grow official APIs for storing and exchanging arbitrary data outside the current storage primitives. Maybe we can shoehorn storage into revlogs in .hg/store/meta. I dunno. Feels like sprint material to me.

I still need to look at this commit in detail, but any commit that alters the on-disk or on-network behavior of Mercurial should ideally be accompanied by a docs change to mercurial/help/internals. I say ideally because some things still aren't documented. But repo requirements are. Please follow up with a patch to document the new requirement in mercurial/help/internals/requirements.txt.