While working on comments I discovered that the rust implementation was different from the C/Python implementation in how it deals with a wrong value of delta chain base.
I made sure that rust code behaves the same as hg there (which is: ignore the corruption) and added a test that checks that.
I don't know about revlog-v1 (it seems there are tests in the tree that are revlog-v1-specific and don't gate against it), but (the lack of) zstd compression is also changing the result, so clearly needs to be guarded against, since it's breaking the --pure build.
I pushed that change. If you have ideas how to make the test less fragile, those would be appreciated. One possibility is to remove the test of corrupted repo altogether, if you think that's better.
I tried to test the series before your last update and it was well in the red (https://foss.heptapod.net/mercurial/mercurial-devel/-/pipelines/30072), and it looks like it's not limited to pure builds. Please test your series through the CI next time.
I think we can forgo that test, it's more trouble than it's worth.
The shell strikes again. :-\
I removed the problematic test, so it should be good now.
I tested the series through a CI as originally submitted, but of course new issues were introduced while it was in review.
Sorry, I need to develop some workflow that allows me to push both to phabricator and to a repo with a CI. Currently I can only do one or the other.
Heptapod's CI will re-send revisions with a differential revision attached to them on pipeline success. Unfortunately, the Windows CI is *very* flaky as of now, which is something we're trying to tackle at the moment.
Believe me, no one is more aggravated than me by the current submission/review workflow.
I'll take a look at your patches later, thank you for re-sending fast.
I'm not sure I understand the point of the hashing done at the very end of the tests: this even causes an issue for Windows for no real reason (rhg doesn't work on Windows yet, but still). Couldn't we just output the file?