##// END OF EJS Templates
upstream » mercurial-mirror
RSS

Clone from https://www.mercurial-scm.org/repo/hg-all

inline-changelog: fix a critical bug in write_pending that delete data...
inline-changelog: fix a critical bug in write_pending that delete data Since a93e52f0b6ff we no longer use inline-revlog for the changelog. The goal there was to solve the lack of testing for the two variants (inline vs split) and reduce the complexity of the interaction with "diverted-write" on the changelog level. However many existing repository still have inline-changelog and we automatically move them to normal revlog as soon as we have the chances. Unfortunately This conversion is buggy and can result in the destruction of the changelog.i if hook triggers the "write pending" mechanism. The bugs comes from the "revlog splitting" logic and the "write_pending" logic stepping over each other. Ironically the change in a93e52f0b6ff aims at no longer having this kind of problem. This changesets fix this issue and add associated tests. Fixing this reveal that the transaction hooks end up not seeing the pending transaction content, because the name is not right ("changelog.i.s.a" instead of "changelog.i.s") we fix this in the next changeset.
Matt Harbison - - Load All Authors

File last commit:

r44031:2e017696 default
r52530:3cf9e52f stable
Show More
censor.txt
22 lines | 1.2 KiB | text/plain | TextLexer
/ mercurial / helptext / internals / censor.txt
History | Annotation | Raw |Copy content |Copy permalink
The censor system allows retroactively removing content from
files. Actually censoring a node requires using the censor extension,
but the functionality for handling censored nodes is partially in core.
Censored nodes in a filelog have the flag ``REVIDX_ISCENSORED`` set,
and the contents of the censored node are replaced with a censor
tombstone. For historical reasons, the tombstone is packed in the
filelog metadata field ``censored``. This allows censored nodes to be
(mostly) safely transmitted through old formats like changegroup
versions 1 and 2. When using changegroup formats older than 3, the
receiver is required to re-add the ``REVIDX_ISCENSORED`` flag when
storing the revision. This depends on the ``censored`` metadata key
never being used for anything other than censoring revisions, which is
true as of January 2017. Note that the revlog flag is the
authoritative marker of a censored node: the tombstone should only be
consulted when looking for a reason a node was censored or when revlog
flags are unavailable as mentioned above.
The tombstone data is a free-form string. It's expected that users of
censor will want to record the reason for censoring a node in the
tombstone. Censored nodes must be able to fit in the size of the
content being censored.