From the VC call today: The use case can be addressed by marking parents as to-be-preserved, so that for merge commits rebase can decide on the parent link is should operate on. It covers a general DAG and is somewhat easier to use in terms of UX than the parentmap, but can provide the same functionality with a multi-step rebase.

I would have to reaudit the parents use, but it wasn't just new code that misbehaves on misordered parents. E.g. memctx.parents for a trivial example. So yes, just backing it out introduces regressions as well.

Just the revert as is introduces other regressions. At the very least, we should preserve the sorting for changelog and keep the original order for filelog. The other part is that the filelog logic here is actively broken even before, so this doesn't fix the logic, just makes it less visibly broken.

Can you comment on how many of them we keep open at a time?

Consider it more a -0, not a very strong objection.

Correct, this stack should have beeen superseded by those.

There are three stages for the revlog and I think we need to teach the transaction playback code at least a bit about this to handle it correctly:

This whole stack exposes a real problem and one quite a bit older, but it is not correct in a number of ways as is.

Silly Python, but this should be fine for all versions we care about. Ironically, it used to be defined the other way around as alias...

Adding more files to the revlog layer sounds like a move in the wrong direction and the motivation here seems quite weak too. Please discuss this with an actual plan on the mailing list.

I don't understand the motivation for this change.

I don't understand this change. We already support none as compression method.

This adds a penalty for the non-inline case?

I'm not sure that this is an improvement. We discussed whether we want to hard-wire the version even stricter ("exactly version 11"), especially because it is hard to predict when the output is going to change again.

Already merged as d55b71393907

Merged as 8d2b62d716b0

Merged as 77e73827a02d

Delayed for now as it doesn't work with the broken changelog.files and needs more efficient manifest logic first.

In D10082#157382, @marmoute wrote:

Do you have any performance number for that update ? for example the time we need to do that full some known large repositories, and the impact on a clone ?

In D10082#157189, @marmoute wrote:

What happens in the stream clone case ? Or during the transition from older to newer client ? streaming content from an older clone will not contains a fully up to date cache, and existing repository neither. How are we dealing with this ?
You mention the need to update the cache after stripping, but I don't see such change in the code. am I missing something ?

Superseded by D10280 and D10290

Superseded by D10290

Superseded by D10290

Superseded by D10290

Superseded by D10290

Superseded by D10290

Superseded by D10290