narrow: remove narrowrevlog Core now automatically enables ellipsis support on revlogs when repositories have narrow enabled. So, we no longer need to globally register the revlog flag as part of activating the narrow extension and this code can be deleted. A side effect of this change is that repositories will now raise an error on encountering an ellipsis flag when the narrow extension is loaded. Previously, loading the narrow extension on a non-narrow repo could result in silent usage of the ellipsis flag. This could lead to undetected bugs. I think the new behavior is more correct. Differential Revision: https://phab.mercurial-scm.org/D4649

localrepo: enable ellipsis flag on revlogs when repo is narrow If the narrow requirement is present, revlogs created for that repository will have the ellipsis flag enabled. This is the same behavior that the narrow extension exhibits. Except the ellipsis flag won't be enabled on repos/revlogs that don't have the narrow requirement. Differential Revision: https://phab.mercurial-scm.org/D4648

revlog: add opener option to enable ellipsis flag processor The ellipsis flag processor can now be registered by specifying an opener option when constructing a revlog instance. This allows us to enable ellipsis flags on a per-revlog basis. Differential Revision: https://phab.mercurial-scm.org/D4647

revlog: store flag processors per revlog Previously, revlog flag processing would consult a global dict when processing flags. This was simple. But it had the undesired side-effect that any extension could load flag processors once and those flag processors would be available to any revlog that was subsequent loaded in the process. e.g. in hgweb, if the narrow extension were loaded for repo A but not repo B, repo B would be able to decode ellipsis flags even though it shouldn't be able to. Making the flag processors dict per-revlog allows us to have per-revlog controls over what flag processors are available, thus preserving desired granular access to flag processors depending on the revlog's needs. If a flag processor is globally registered, it is still globally available. So this commit should not meaningfully change behavior. Differential Revision: https://phab.mercurial-scm.org/D4646

revlog: define ellipsis flag processors in core We will soon be teaching core to honor the ellipsis flag on revlogs. Moving the definition of the processor functions to core is the first step in this. The processor is still not registered unless the narrow extension is loaded. Differential Revision: https://phab.mercurial-scm.org/D4645

narrow: remove custom filelog type This functionality is now handled by core as of the previous commit. I wanted this to be a standalone commit because the deleted code makes a reference to remotefilelog's file type missing a node() method and this may have implications to narrow+remotefilelog usage. The code in core doesn't perform this check and therefore behavior may be subtly different and buggy. But I /think/ the check is merely a performance optimization and nothing more. So I'm optimistic this will continue to "just work." Differential Revision: https://phab.mercurial-scm.org/D4644

filelog: custom filelog to be used with narrow repos Narrow repos may have file revisions whose copy/rename metadata references files not in the store. This can pose problems when consumers attempt to access a missing referenced file revision. The narrow extension hacks around this problem by implementing a derived filelog type that provides custom implementations of renamed(), size(), and cmp() which handle renames against files not in the narrow spec by silently removing the rename metadata. While silently dropping metadata isn't the most robust solution, it is the easiest to implement. This commit ports the custom narrow filelog class to core. When a narrow repo is constructed, its ifilestorage creation function will automatically use the new filelog type. This means the extra logic is 0 cost for non-narrow repos and shouldn't interfere with their operation. Differential Revision: https://phab.mercurial-scm.org/D4643