Maybe the server could reject such changes, but I'd rather simply roll clients with the fix.

It seems that this kind of corruption can propagate between clones as well. Sadness.

In D11212#174950, @danchr wrote:

In D11212#174786, @danchr wrote:

In D11212#174524, @Alphare wrote:

Thanks for bringing this up. Does that represent a large amount of work for you?

Well, my main challenge here is that I have absolutely no idea what's going on — I don't have much experience with the very low levels of networking in Mercurial, or the (relatively) new peer API. It seems to me that the point of that code is, essentially, to provide a minimal repository or peer that does nothing. Could something like that be moved to Mercurial core?

Okay, I managed to fix it:
https://foss.heptapod.net/mercurial/hg-git/-/merge_requests/130/diffs
https://foss.heptapod.net/mercurial/hg-git/-/merge_requests/131/diffs
Would one of you perhaps take a look at those changes and see if they make sense? I did it in the form of a decorator that just wraps a regular function returning a value. Something like that might be useful for core as well, and simplify a simple method like branchmap().

I think this should be fixed. If I understand the diff correctly, it was a slash vs backslash change, and the rest is noise.

I am definitely not going to write a test. I know nothing about remotefilelog. I merely happened to see this while grepping around.

I have been assuming that changes can still be submitted during a change freeze, but they are just going to get ignored for a few days. None of my changes are particularly intended to go on 5.9.

Maybe the forward slashes in the extension created at the beginning of the test is the source of the other windows failures?

Also, can you put (issue6423) in the first line of the commit message, so the bugzilla magic closes the issue?

Does the order of the truncates actually not matter, for concurrent readers? I don't really see how it could matter (linkrevs should make it possible to ignore everything not committed), but before looking at the rollback code, I imagined it truncated in reverse order of writes (and looking it up, it's what's described in the initial revlog paper).

I knew zstd could be turned off, but I didn't knew there was an option to turn off even zlib. Cool.

In D10712#163295, @joerg.sonnenberger wrote:

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.
First of all, the check added in 8502f76dbfd7 is broken for the revlog inline to non-inline migration.