Show More
@@ -0,0 +1,22 | |||||
|
1 | The censor system allows retroactively removing content from | |||
|
2 | files. Actually censoring a node requires using the censor extension, | |||
|
3 | but the functionality for handling censored nodes is partially in core. | |||
|
4 | ||||
|
5 | Censored nodes in a filelog have the flag ``REVIDX_ISCENSORED`` set, | |||
|
6 | and the contents of the censored node are replaced with a censor | |||
|
7 | tombstone. For historical reasons, the tombstone is packed in the | |||
|
8 | filelog metadata field ``censored``. This allows censored nodes to be | |||
|
9 | (mostly) safely transmitted through old formats like changegroup | |||
|
10 | versions 1 and 2. When using changegroup formats older than 3, the | |||
|
11 | receiver is required to re-add the ``REVIDX_ISCENSORED`` flag when | |||
|
12 | storing the revision. This depends on the ``censored`` metadata key | |||
|
13 | never being used for anything other than censoring revisions, which is | |||
|
14 | true as of January 2017. Note that the revlog flag is the | |||
|
15 | authoritative marker of a censored node: the tombstone should only be | |||
|
16 | consulted when looking for a reason a node was censored or when revlog | |||
|
17 | flags are unavailable as mentioned above. | |||
|
18 | ||||
|
19 | The tombstone data is a free-form string. It's expected that users of | |||
|
20 | censor will want to record the reason for censoring a node in the | |||
|
21 | tombstone. Censored nodes must be able to fit in the size of the | |||
|
22 | content being censored. |
General Comments 0
You need to be logged in to leave comments.
Login now