revlog: verify censored flag when hashing added revision fulltext When receiving a delta via exchange, three possible storage outcomes emerge: 1. The delta is added directly to the revlog. ("fast-path") 2. A freshly-computed delta with a different base is stored. 3. The new revision's fulltext is computed and stored outright. Both (2) and (3) require materializing the full text of the new revision by applying the delta to its base. This is typically followed by a hash check. The new flags argument allows callers to _addrevision to signal that they expect that hash check to fail. We can use this opportunity to verify that expectation. If the hash fails, require the flag be set; if the hash passes, require the flag be unset. Rather than simply eliding the hash check, this approach provides some assurance that the censored flag is not applied to valid revisions. Read more at: http://mercurial.selenic.com/wiki/CensorPlan

revlog: add flags argument to _addrevision, update callers use default flags For revlog index flags to be useful to other parts of Mercurial, they need to be settable when writing revisions. The current use case for revlog index flags is the censorship feature: http://mercurial.selenic.com/wiki/CensorPlan While the censor flag could be inferred in _addrevision by interrogating the text/delta being added, that would bury the censorship logic and inappropriately couple it to all revision creation.

revlog: define censored flag for revlogng index This flag bit will be used to cheaply signal censorship presence to upper layers (exchange, verify). It indicates that censorship metadata is present but does not attest to the verifiability of that metadata. For the censorship design, see: http://mercurial.selenic.com/wiki/CensorPlan

localrepo: remove all internal uses of localrepo.wopener It has been replaced with localrepo.wvfs.

localrepo: remove all internal uses of localrepo.sopener It has been replaced with localrepo.svfs.

localrepo: remove all internal uses of localrepo.opener It has been replaced with localrepo.vfs. In the future we may split the vfs into different vfs objects to access different elements of the repository.