Gregory Szorc <gregory.szorc@gmail.com> [Thu, 13 Sep 2018 15:57:18 -0700] rev 39786
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
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 13 Sep 2018 15:52:42 -0700] rev 39785
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
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 13 Sep 2018 15:48:53 -0700] rev 39784
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