[PATCH] obsolete: experimental flag to get debug about obsmarkers exchange

[Martin von Zweigbergk]

On Tue, Apr 14, 2015 at 1:24 PM Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 04/14/2015 04:15 PM, Martin von Zweigbergk wrote:
> >
> >
> > On Tue, Apr 14, 2015 at 10:06 AM Pierre-Yves David
> > <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
> > wrote:
> >
> >     # HG changeset patch
> >     # User Pierre-Yves David <pierre-yves.david at fb.com
> >     <mailto:pierre-yves.david at fb.com>>
> >     # Date 1429026244 14400
> >     #      Tue Apr 14 11:44:04 2015 -0400
> >     # Node ID b36bddb86b281eb6c4abd631c57eec47f6de5198
> >     # Parent  c229ba58b956c7872af7ed220ad5099ea4a6ecf7
> >     obsolete: experimental flag to get debug about obsmarkers exchange
> >
> >     The obsolescence markers exchange is still experimental. We
> >     (developer) need
> >     more information about what is going on. I'm adding an experimental
> >     flag to add
> >     display the amount of data exchanged during bundle2 exchanges.
> >
> >     diff --git a/mercurial/bundle2.py b/mercurial/bundle2.py
> >     --- a/mercurial/bundle2.py
> >     +++ b/mercurial/bundle2.py
> >     @@ -1215,11 +1215,15 @@ def handlepushkeyreply(op, inpart):
> >
> >       @parthandler('obsmarkers')
> >       def handleobsmarker(op, inpart):
> >           """add a stream of obsmarkers to the repo"""
> >           tr = op.gettransaction()
> >     -    new = op.repo.obsstore.mergemarkers(tr, inpart.read())
> >     +    markerdata = inpart.read()
> >     +    if op.ui.config('experimental', 'obsmarkers-exchange-debug',
> >     False):
> >
> >
> > Why a new config instead of the usual --debug flag?
>
> I want information about that in every single push/pull operation I'll
> run. I'm not going run with --debug all the time. It would be in the
> [devel] section. But this is not a warning so I do not want it into this
> warning related section.
>

Who else than you would enable it? If it's the same set of people who would
enable [devel], then maybe it's worth expanding the meaning of that section
to include non-warning messages for developers?


>
> --
> Pierre-Yves David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150415/f7d86890/attachment.html>