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

[Pierre-Yves David]

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.


-- 
Pierre-Yves David