[PATCH followup V2] obsmarker: add an experimental flag controlling "operation" recording

[Yuya Nishihara]

On Fri, 19 May 2017 20:48:06 -0700, Jun Wu wrote:
> Excerpts from Pierre-Yves David's message of 2017-05-20 03:23:58 +0200:
> > # HG changeset patch
> > # User Pierre-Yves David <pierre-yves.david at octobus.net>
> > # Date 1495242623 -7200
> > #      Sat May 20 03:10:23 2017 +0200
> > # Node ID 678a4a8fe4f511f3707a2dd5445dbc96a07da6aa
> > # Parent  3546a771e376f55e7051149673d368d53d85f8d0
> > # EXP-Topic operation
> > # Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ 
> > #              hg pull https://www.mercurial-scm.org/repo/users/marmoute/mercurial/  -r 678a4a8fe4f5
> > obsmarker: add an experimental flag controlling "operation" recording
> > 
> > It seems better to introduce the experiment behing a flag for now as there are
> > multiple concerns around the feature:
> > 
> >  * Storing operation increase the size of obsolescence markers significantly
> >    (+10-20%).
> 
> Since I have a plan to de-duplicate all strings (and other issues) and could
> probably send some RFCs in one week. And I'd expect that to change the
> "10-20%" number greatly.
> 
> Maybe give me one week to see what happens before making a decision on this
> patch.

That will only address the first bullet point, right? I don't want to leave
the experimental implementation affecting storage layer for a week, so queued.

> >  * It performs poorly when exchanging markers (cannot combine command
> >    names, command name might be unknown remotely, etc)