On 12/24/2016 08:48 PM, Augie Fackler wrote:
On Sat, Dec 24, 2016 at 07:30:57PM +0100, Pierre-Yves David wrote:
On 12/24/2016 05:36 PM, Remi Chaintron wrote:
# HG changeset patch
# User Remi Chaintron <r...@fb.com>
# Date 1482451718 18000
# Thu Dec 22 19:08:38 2016 -0500
# Node ID c1bd9b7750cdfe1f2a1437e4ba0ed8f6e48b2dd1
# Parent 4f72f28e527c72cae072880b8fa1610c0289dded
documentation: better censor flag documentation.
diff --git a/mercurial/help/internals/revlogs.txt
b/mercurial/help/internals/revlogs.txt
--- a/mercurial/help/internals/revlogs.txt
+++ b/mercurial/help/internals/revlogs.txt
@@ -89,7 +89,7 @@
Absolute offset of revision data from beginning of revlog.
6-7 (2 bytes)
Bit flags impacting revision behavior. The following bit offsets define:
- 0: 'censor' extension flag.
+ 0: REVIDX_ISCENSORED indicates the revision has censored metadata.
From my understanding of censor, I would have expected something more like
"the revision content is censored". If I remember correctly, the censors
flag means the revision content has been nuked, the metadata are more a
secondary things that give a bit more details about that nuking.
What do you think ?
My recollection matches, for anyone following along. The metadata is a
hack that predates changegroup3 being able to exchange revlog flags,
so the in-content revlog flagging is a hack so that censored nodes can
be exchanged.
Good point, So if I get that right, the source of truth is the meta-data
and the flag is just and "optimisation" then. We should update the
internal doc to point this trickery if its not already the case.
--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
