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

Martin von Zweigbergk martinvonz at google.com
Wed Nov 5 11:17:52 CST 2014


On Wed Nov 05 2014 at 9:14:29 AM Pierre-Yves David <
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>> 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>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20141105/9ac44f52/attachment-0001.html>


More information about the Mercurial-devel mailing list