Mercurial 3.2 can apparently fail to recognize outgoing changes, causing push to fail to do its job. The first bad revision is: changeset: 23084:3ef893520a85 branch: stable user: Pierre-Yves David <pierre-yves.david@fb.com> date: Mon Oct 27 17:52:33 2014 +0100 summary: setdiscovery: limit the size of the initial sample (issue4411) I guess the logic behind the change is flawed as things are now. Missing heads are not picked up later. I will try to find a test case.
I'm not too surprise it break. But could not find a test case were it do. eagerly waiting for your testcase.
adding the keyword and making the tite more clear
Fixed by http://selenic.com/repo/hg/rev/86c35b7ae300 Mads Kiilerich <madski@unity3d.com> discovery: limit 'all local heads known remotely' to real 'all' (issue4438) 3ef893520a85 made it possible that the initial head check didn't include all heads. If that is the case, don't use the early exit just because this random sample happened to be 'all known'. Note: the randomness in the discovery protocol can make this problem hard to reproduce. (please test the fix)
Fixed by http://selenic.com/repo/hg/rev/73cfaa348650 Mads Kiilerich <madski@unity3d.com> discovery: indices between sample and yesno must match (issue4438) 3ef893520a85 changed 'sample' from a list to a set. The iteration order is thus undefined and the yesno indices are not stable. To solve this, repeat the listification and comment from elsewhere in the code. Note: the randomness in the discovery protocol can make this problem hard to reproduce. (please test the fix)
Fixed by http://selenic.com/repo/hg/rev/c1f370dab456 Mads Kiilerich <madski@unity3d.com> discovery: test coverage for issue4438 / 86c35b7ae300 / 73cfaa348650 The randomness in the discovery protocol made this problem hard to reproduce. The test mocks random.sample to make sure we hit the problem every time. The set iteration order also made the output unstable ... but with the issue fixed, it is stable. (please test the fix)
Bulk testing -> fixed