[PATCH censor RFC] revlog: addgroup checks if incoming deltas add censored revs, sets flag bit

Michael Edgar adgar at google.com
Mon Mar 9 22:23:26 CDT 2015

On Mon, Mar 9, 2015 at 10:37 PM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

> On 03/09/2015 12:56 PM, Mike Edgar wrote:
>> # HG changeset patch
>> # User Mike Edgar <adgar at google.com>
>> # Date 1421266568 18000
>> #      Wed Jan 14 15:16:08 2015 -0500
>> # Node ID 816f69e12902d419421bb148705f7bc65e0f7774
>> # Parent  02d7b5cd373bbb4e8263dad9bfbf9c4c3b0e4e3a
>> revlog: addgroup checks if incoming deltas add censored revs, sets flag
>> bit
>> A censored revision stored in a revlog should have the censored revlog
>> index
>> flag bit set. This implies we must know if a revision is censored before
>> we
>> add it to the revlog. When adding revisions from exchanged deltas, we
>> would
>> prefer to determine this flag without decoding every single full text.
>> This change introduces a heuristic based on assumptions around the
>> Mercurial
>> delta format and filelog metadata. Since deltas which produce a censored
>> revision must be full-replacement deltas, we can read the delta's first
>> bytes
>> to check the filelog metadata. Since "censored" is the alphabetically
>> first
>> filelog metadata key, censored filelog revisions have a well-known prefix
>> we
>> can look for.
>> For more on the design and background of the censorship feature, see:
>> http://mercurial.selenic.com/wiki/CensorPlan
> This approach looks like like a recipe for disaster. (expecially the one
> relying on "censored" being the first entry by alphabetical order.

Agreed it's suboptimal. Perhaps I could parse all the metadata,
line-by-line, instead? That might make this a precise approach and not just
a heuristic.

> What do you miss in the protocol to makes it happen ? as far as I
> understand the censored feature requires bundle2 to be used. Bundle2 is not
> the default yet so you have a windows for protocol improvement.

Bundle2 is not required, and in fact supporting older clients which don't
have bundle2 support is an explicit design goal. What's missing is
changegroups don't transfer the "flags" of a revision (since those flags
were unused until the censorship design).

A changegroup v3 could add a 16-bit flags field which obviates this
heuristic for new clients and servers, but supporting mercurial back to 1.x
is in scope for censorship.

> Though?
> --
> Pierre-Yves David

Michael Edgar | Software Engineer | adgar at google.com | 518-496-6958
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150309/1206bae5/attachment.html>

More information about the Mercurial-devel mailing list