martinvonz added a comment.
In https://phab.mercurial-scm.org/D2647#93458, @gracinet wrote: > In https://phab.mercurial-scm.org/D2647#93457, @martinvonz wrote: > > > In https://phab.mercurial-scm.org/D2647#93456, @marmoute wrote: > > > > > We could maybe make it a function of both the number of heads and roots. That is not strictly the number of connected set, but that would provide a more conservative approach. That could over-sample for hour-glass shape, but they are probably less common. > > > > > > The current way (only consider roots) should not over-sample, right? It still seems very effective in practice. > > > I suppose it will if you have thousands of roots converging to one point, then that point diverging again towards thousands of heads, all of that actually missing from the remote, but anyway, the current random wouldn't catch that either. Right, I also thought of that case, but it just seemed too obscure to worry about. > Anyway, basing on the number of roots is biased towards cases where lots of independents branches are missing from the remote, like in the use case from the commit message, whereas basing on the number of heads would be biased towards lots of independent branches being common (while not being remote heads, since we know them already, hence, cases where they have been merged in the remote). I imagine the latter being quite common as well. > > I would be in favor of something based on both. I'm happy with what we get for this simple change, but feel free to send a followup. > Still I start feeling like we should be a bit cautious with the impact on all of this on network time and remote servers CPU time in practical cases (although the 'known' question is quite fast). At which threshold would an additional roundtrip be actually faster for everyone ? I agree with you in principle. Roundtrips also cost a bit in terms of CPU and bandwidth, so it's probably not a big concern? REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D2647 To: martinvonz, #hg-reviewers, indygreg, marmoute Cc: gracinet, indygreg, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel