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

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

narrow: only send the narrowspecs back if ACL in play...
narrow: only send the narrowspecs back if ACL in play I am unable to think why we need to send narrowspecs back from the server. The current state adds a 'narrow:spec' part to each changegroup which is generated when narrow extension is enabled. So we are sending narrowspecs on pull also. There is a problem with sending the narrowspecs the way we are doing it right now. We add include and exclude as parameter of the 'narrow:spec' bundle2 part. The the len of include or exclude string increase 255 which is obvious while working on large repos, bundle2 generation code breaks. For more on that refer issue5952 on bugzilla. I was thinking why we need to send the narrowspecs back, and deleted the 'narrow:spec' bundle2 part generation code and found that only narrow-acl test has some failure. With this patch, we will only send the 'narrow:spec' bundle2 part if ACL is enabled because the original narrowspecs in those cases can be a subset of narrowspecs user requested. There are phase related output change in couple of tests. The output change shows that we are now dealing in public phases completely. So maybe sending the narrow:spec bundle2 part was preventing phases being exchanged or phase bundle2 data being applied. Differential Revision: https://phab.mercurial-scm.org/D4931
Augie Fackler - - Load All Authors

File last commit:

r31280:1b699a20 default
r40373:cb516a85 default
Show More
censor.txt
22 lines | 1.2 KiB | text/plain | TextLexer
/ mercurial / help / 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.