Fri, 14 Aug 2020 20:45:49 -0700 worker: don't expose readinto() on _blockingreader since pickle is picky
Martin von Zweigbergk <martinvonz@google.com> [Fri, 14 Aug 2020 20:45:49 -0700] rev 45390
worker: don't expose readinto() on _blockingreader since pickle is picky The `pickle` module expects the input to be buffered and a whole object to be available when `pickle.load()` is called, which is not necessarily true when we send data from workers back to the parent process (i.e., it seems like a bad assumption for the `pickle` module to make). We added a workaround for that in https://phab.mercurial-scm.org/D8076, which made `read()` continue until all the requested bytes have been read. As we found out at work after a lot of investigation (I've spent the last two days on this), the native version of `pickle.load()` has started calling `readinto()` on the input since Python 3.8. That started being called in https://github.com/python/cpython/commit/91f4380cedbae32b49adbea2518014a5624c6523 (and only by the C version of `pickle.load()`)). Before that, it was only `read()` and `readline()` that were called. The problem with that was that `readinto()` on our `_blockingreader` was simply delegating to the underlying, *unbuffered* object. The symptom we saw was that `hg fix` started failing sometimes on Python 3.8 on Mac. It failed very relyable in some cases. I still haven't figured out under what circumstances it fails and I've been unable to reproduce it in test cases (I've tried writing larger amounts of data, using different numbers of workers, and making the formatters sleep). I have, however, been able to reproduce it 3-4 times on Linux, but then it stopped reproducing on the following few hundred attempts. To fix the problem, we can simply remove the implementation of `readinto()`, since the unpickler will then fall back to calling `read()`. The fallback was added a bit later, in https://github.com/python/cpython/commit/b19f7ecfa3adc6ba1544225317b9473649815b38. However, that commit also added checking that what `read()` returns is a `bytes`, so we also need to convert the `bytearray` we use into that. I was able to add a test for that failure at least. Differential Revision: https://phab.mercurial-scm.org/D8928
Thu, 27 Aug 2020 09:06:35 +0200 test: add `test-repo` requirement to `test-check-format` (issue6395) stable 5.5.1
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 27 Aug 2020 09:06:35 +0200] rev 45389
test: add `test-repo` requirement to `test-check-format` (issue6395) Kindly reported by Tristan Seligmann <mithrandi@mithrandi.net>
Tue, 18 Aug 2020 15:03:57 -0700 commit: clear mergestate also with --amend (issue6304)
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Aug 2020 15:03:57 -0700] rev 45388
commit: clear mergestate also with --amend (issue6304) The `hg commit --amend` uses the in-memory code, which naturally doesn't touch the merge state (well, it shouldn't anyway; I think I've fixed bugs in that area recently). We therefore need to clear the mergestate after calling `repo.commitctx()` since we expect that from `hg commit --amend`. Differential Revision: https://phab.mercurial-scm.org/D8932
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 tip