[PATCH 1 of 2 stable] discovery: limit 'all local heads known remotely' to real 'all' (issue4438)

[Martin von Zweigbergk]

On Wed Nov 05 2014 at 9:21:26 AM Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 11/05/2014 05:17 PM, Martin von Zweigbergk wrote:
> >
> >
> > On Wed Nov 05 2014 at 9:14:29 AM Pierre-Yves David
> > <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
> > wrote:
> >
> >
> >
> >     On 11/05/2014 05:12 PM, Martin von Zweigbergk wrote:
> >      >
> >      >
> >      > On Wed Nov 05 2014 at 9:07:15 AM Matt Mackall <mpm at selenic.com
> >     <mailto:mpm at selenic.com>
> >      > <mailto:mpm at selenic.com <mailto:mpm at selenic.com>>> wrote:
> >      >
> >      >     On Wed, 2014-11-05 at 16:48 +0000, Martin von Zweigbergk
> wrote:
> >      >      > On Wed Nov 05 2014 at 4:07:26 AM Mads Kiilerich
> >      >     <mads at kiilerich.com <mailto:mads at kiilerich.com>
> >     <mailto:mads at kiilerich.com <mailto:mads at kiilerich.com>>> wrote:
> >      >      > >
> >      >      > > Note: the randomness in the discovery protocol can make
> this
> >      >     problem hard
> >      >      > > to
> >      >      > > reproduce.
> >      >      > >
> >      >      >
> >      >      > A little off-topic, but is there a way to reduce the
> >     randomness?
> >      >     Would
> >      >      > simply always using the same random seed be okay? Or
> >     basing it on
> >      >     some
> >      >      > repository state?
> >      >
> >      >     We've actually got this tidbit in commands:debugsetdiscovery:
> >      >
> >      >          # make sure tests are repeatable
> >      >          random.seed(12323)
> >      >
> >      >     One of the benefits of NOT having such a seed is that we
> >     sometimes
> >      >     discover bugs when the RNG takes us somewhere new.
> >      >
> >      > Makes sense. Is that just by accident, though? I.e, did you
> consider
> >      > always using the same seed (or, again, based on some repo state)?
> An
> >      > obvious benefit of using a deterministic seed is that you can just
> >      > re-run a failed pull with --traceback, which I suppose you cannot
> >      > currently do.
> >
> >     The approach we use in the test is to display the seed used. Could
> >     include the seed used when discovery failed to be able to repro more
> >     easily.
> >
> >
> > Oh, I see. So the seed is deterministic outside of tests as well; it's
> > just printed only in tests. Sorry about the noise then.
>
> It is currently not deterministic outside of test.
>
> What I'm trying to says is:
> - non deterministic seed is good for wider testing
> - having the ability to fix the seed is good for reproductability
>
> We use a random but enforceable seed for python hashing in the test. We
> could use the same approach for discovery.
>

 Ah, now I understand (after looking at run-tests). I'm for making it
possible to reproduce a failure in production. I suppose that means moving
the PYTHONHASHSEED stuff into core. I would honestly prefer a fixed seed,
so even users who have no idea about the implementation will see
deterministic behavior (barring network delays and outages etc, of course).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20141105/a70bd492/attachment.html>