Previously, the revlog class implemented dummy methods for
various censor-related functionality. Revision censoring was
(and will continue to be) only possible on filelog instances.
So filelog implemented these methods to perform something
A problem with implementing censoring on filelog is that
it assumes filelog is a revlog. Upcoming work to formalize
the filelog interface will make this not true.
Furthermore, the censoring logic is security-sensitive. I
think action-at-a-distance with custom implementation of core
revlog APIs in derived classes is a bit dangerous. I think at
a minimum the censor logic should live in revlog.py.
I was tempted to created a "censored revlog" class that
basically pulled these methods out of filelog. But, I wasn't
a huge fan of overriding core methods in child classes. A
reason to do that would be performance. However, the censoring
code only comes into play when:
- hash verification fails
- delta generation
- applying deltas from changegroups
The new code is conditional on an instance attribute. So the
overhead for running the censored code when the revlog isn't
censorable is an attribute lookup. All of these operations are
at least a magnitude slower than a Python attribute lookup. So
there shouldn't be a performance concern.