Ah, I see. The move from ('plain', '') to ('', 'plain') is matching the key used for the vfsmap?
If so, go ahead with this patch on stable.

Can we go fully explicit ? Having both plain and store as the possible value?

(I did some experiment, here seems a good spot to report them)

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.

Can you indicate a summary of the total speedup of the series ? (from base to last changesets?). Also I am not sure for which case these number apply ? Is this the compatibility mode or after repository conversion ? Can we have number for both ?

Something only based on the number of root can also over sample. For a "simple" example, imagine a undecideded set with many roots that eventually all merge into a few heads.
If most of that set is common between local and remote, few question about the part of the history at the heads will quickly "decide" many changesets. Numberous questions at the roots part of the history won't.

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.

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.

There used to be a experimental.graph-group-branches (that tortoise-hg
still use) that got removed at some point. Did you check the rational
behind the removal ?

+1 on the idea of an explcit editable file instead of immutable static entry in the changelog. I would use it.

This one seems simple and sensible.

That one seems simple and sensible too.

This one seems simple and sensible.

I did a first path through it, the new code seems reasonable and easier
to read than the previous one. Some comments and questions below.

I am quite enthousiastic for a non-filelog based copy tracing using commit level information. However, I am very unenthousiastic at the idea of storing more copy data in the changeset itself. The "files" field in the changelog is already quite problematic (about 95% for changelog.d file, taking possibily hundred of megabytes). In addition, stoing copy in the changeset is kind of a "schema breakage" making its adoption slower.

Thanks looks good to me. Thanks for clarifying the table.

+1

In D6140#89738, @martinvonz wrote:

In D6140#89733, @marmoute wrote:

[…]
What Martin is trying to achieve here is a simple function to express
X::X. So maybe it could be a special case of a function expression X::Y.
However, we don't have this function right now. Maybe we jut need to
introduce it, with a clear name eg revbetween or connected or
dagrange, with an optionnal second arguments:

• X::Y → dagrange(X, Y)
• X::X → dagrange(X)

And ::X and X::? Maybe dagrange(heads=X) and dagrange(roots=X), respectively? That implies that roots and heads default to null and heads(), but it seems weird that dagrange(X) is equivalent to dagrange(roots=X, heads=X).

I spend some more time thinking about it, especially about the semantic
I would expect from a contiguous function. My conclusion is that I'm
seeing something call contiguous more as a filter than something
adding element to the set.