revlog: move censor logic out of censor extension
The censor extension is doing very low-level things with revlogs.
It is fundamentally impossible for this logic to remain in the censor
extension while support multiple storage backends: we need each
storage backend to implement censor in its own storage-specific
way.
This commit effectively moves the revlog-specific censoring code to
be a method of revlogs themselves.
We've defined a new API on the file storage interface for censoring
an individual node. Even though the current censoring code doesn't
use it, the API requires a transaction instance because it logically
makes sense for storage backends to require an active transaction
(which implies a held write lock) in order to rewrite storage.
After this commit, the censor extension has been reduced to
boilerplate precondition checking before invoking the generic
storage API.
I tried to keep the code as similar as possible. But some minor
changes were made:
* We use self._io instead of instantiating a new revlogio instance.
* We compare self.version against REVLOGV0 instead of != REVLOGV1
because presumably all future revlog versions will support censoring.
* We use self.opener instead of going through repo.svfs (we don't have
a handle on the repo instance from a revlog).
* "revlog" dropped
* Replace "flog" with "self".
Differential Revision: https://phab.mercurial-scm.org/D4656
Integration with the share extension needs improvement. Right now
we've seen some odd bugs, and the way we modify the contents of the
.hg/shared file is unfortunate. See wrappostshare() and unsharenarrowspec().
Resolve commentary on narrowrepo.wraprepo.narrowrepository.status
about the filtering of status being done at an awkward layer. This
came up the import to hgext, but nobody's got concrete improvement
ideas as of then.
Address commentary in manifest.excludedmanifestrevlog.add -
specifically we should improve the collaboration with core so that
add() never gets called on an excluded directory and we can improve
the stand-in to raise a ProgrammingError.
Reason more completely about rename-filtering logic in
narrowfilelog. There could be some surprises lurking there.
Formally document the narrowspec format. Unify with sparse, if at all
possible. For bonus points, unify with the server-specified narrowspec
format.
narrowrepo.setnarrowpats() or narrowspec.save() need to make sure
they're holding the wlock.