On 12/28/2016 05:25 PM, Augie Fackler wrote:
(bcc adgar in case he can provide insight, but I don’t know if he
remembers or if he’s on vacation this/next week at all)
On Dec 28, 2016, at 11:20 AM, Pierre-Yves David
<pierre-yves.da...@ens-lyon.org
<mailto:pierre-yves.da...@ens-lyon.org>> wrote:
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.
I think the flag is authoritative, but in order to work with cg < 3 the
metadata is sometimes “authoritative” when being moved through a bundle.
I’m far more comfortable treating the flag as authoritative, and
documenting the metadata structure as an important hack, which serves
two purposes:
1) It gives us a tombstone to put in the revlog contents
2) When using “old” transfer mechanisms, we don’t lose the censor state.
This make sense but it start to be subtle enough that I think it is
worth documenting for the next poor souls looking into this. Can I get
you or Adgar to send a documentation patch about this. I think we are at
a point where mercurial/help/internals/censors.txt would make sense.
Cheers,
--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
