The proof of concept part is primarily that we can get the benefit with minimal refactoring of the existing rbc implementation. The actual use is a bit more complicated as the actual topicmap would be part of an extension and therefore hook up differently. But the interaction is much easier to understand like this, IMO.
I like where this is headed. Thank you for doing this work. I can see this patch can be split into at least 3 different patches which will help speed up review.
This movement of variables can be a separate patch and will be easy one to queue making this patch a bit lighter to review.
Probably we can have an interface for generic name-cache.
This and related changes should be a separate patch.
Right, the primary goal of this PoC is to outline what changes are necessary and what the impact is for supporting more than just the branch mapping. It doesn't make sense as is since it is provided for the benefit out of currently out-of-tree target. So the goal is to get a consensus on whether the cache is useful enough for the topic extension and if it is, split this patch into smaller pieces, figure out a few details in the method naming (e.g. branchinfo is tight to the current functionality) in core and how to integrate the rest backwards compatible in the topic extension.
As mentioned in the review for the parent, doing a lookup here is expensive and should be avoided. The extra=None case is essentially only used for nullrev. The function name is not terribly good, parsechangeset or so would make a lot more sense in the generalized cache.
Yes, but it is a breaking change for topic.