This is going to break our server. Can you make it work with existing servers for a while (behave differently depending on capability, I suppose), so we can get a chance to transition? I would think it's not going to be terribly hard, but let me know if it would take more time than you have and I'll try to help.

In D6432#93545, @yuja wrote:

@@ -1384,26 +1384,26 @@

>>> _rootsdirsandparents(
...     [(b'glob', b'g/h/*', b''), (b'glob', b'g/h', b''),
...      (b'glob', b'g*', b'')])

• (['g/h', 'g/h', ''], [], ['', 'g']) + (['g/h', 'g/h', ''], [], set(['', 'g']))

Perhaps, this would break py3 doctests. The repr syntax changed.

In D6422#93543, @marmoute wrote:

The nodes in the above example have been selected by a script because they had interresting property. They are not based on a tag so I can't give you one. How did you converted the repo ? I think hg convert keeps a map somewhere, otherwise, using the commit message could work.

In D6422#93466, @marmoute wrote:

Can you indicate a summary of the total speedup of the series ? (from base to last changesets?).

In D2647#93458, @gracinet wrote:

In D2647#93457, @martinvonz wrote:

In 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.

In 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.

In D2647#93258, @martinvonz wrote:

In D2647#93256, @marmoute wrote:

I feel like I am missing something. Your commit message seems to be talking using at least as many item in the sameple than there is independant connected set. However your code seems to use "heads(undecided)" that is a quite different. Using independant connected set seems like a good trade off (but might be expensive to compute). Using all heads can significantly bloat the discovery without giving it a significant edge in many cases.

Good point. The case I can think of is when you have a tree of commits on the local side. Something like this:

o
| o
| | o
| | | o
| | |/
| |/
| o
| |
| o
| |
| o
|/
o
~

If we have a long sequence of commits there and many heads, we would increase the sampling of the (mostly-)linear part unnecessarily. I'll see if there's an easy way to improve that.

In D2647#93256, @marmoute wrote:

I feel like I am missing something. Your commit message seems to be talking using at least as many item in the sameple than there is independant connected set. However your code seems to use "heads(undecided)" that is a quite different. Using independant connected set seems like a good trade off (but might be expensive to compute). Using all heads can significantly bloat the discovery without giving it a significant edge in many cases.