Tue, 08 Oct 2024 21:46:22 +0200 branching: merge stable into default
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Oct 2024 21:46:22 +0200] rev 51993
branching: merge stable into default
Fri, 04 Oct 2024 13:26:29 -0400 tests: provide an alternate fake lock for filesystems without symlink support
Matt Harbison <matt_harbison@yahoo.com> [Fri, 04 Oct 2024 13:26:29 -0400] rev 51992
tests: provide an alternate fake lock for filesystems without symlink support
Fri, 04 Oct 2024 12:53:02 -0400 tests: disable `worker.backgroundclose` to stabilize a test on Windows
Matt Harbison <matt_harbison@yahoo.com> [Fri, 04 Oct 2024 12:53:02 -0400] rev 51991
tests: disable `worker.backgroundclose` to stabilize a test on Windows TIL that `worker.enabled=0` doesn't prevent these workers from spinning up. At any rate, there's already a whole lot of conditionalized output following `cat client.log`, the placement of the "starting 4 threads for background file closing" message seems unstable, and we don't care about those worker threads here. Preventing the message is better for test maintenance.
Fri, 04 Oct 2024 11:22:30 -0400 tests: fix lock file path mangling in `test-racy-mutations.t` on Windows
Matt Harbison <matt_harbison@yahoo.com> [Fri, 04 Oct 2024 11:22:30 -0400] rev 51990
tests: fix lock file path mangling in `test-racy-mutations.t` on Windows I guess `$TESTTMP_FORWARD_SLASH` gets translated by MSYS. This was in the `.foo_commit_out` file: sh: C;C:\\MinGW\\msys\\1.0\\Users\\Matt\\AppData\\Local\\Temp\\hgtests.1qc8jmdl\\child2\\test-racy-mutations.t-skip-detection\\waitlock_editor.sh: $ENOENT
Fri, 04 Oct 2024 11:10:45 -0400 tests: stabilize `test-status-eacces.t` on Windows
Matt Harbison <matt_harbison@yahoo.com> [Fri, 04 Oct 2024 11:10:45 -0400] rev 51989
tests: stabilize `test-status-eacces.t` on Windows As noted earlier, `chmod` doesn't complain in MSYS, but also doesn't alter the file permissions such that they are unreadable. I'm guessing the other lines of output in this area that are gated on `rhg` (or not) will also need this, but I don't want to dig too deeply into something that is apparently working well enough.
Fri, 04 Oct 2024 01:40:35 -0400 run-tests: bump the default timeout on Windows to 4x the normal value
Matt Harbison <matt_harbison@yahoo.com> [Fri, 04 Oct 2024 01:40:35 -0400] rev 51988
run-tests: bump the default timeout on Windows to 4x the normal value There are a ridiculous number of tests that timeout on Windows with the 360 sec default (~60). And because of the bug where timed out tests still run to completion before the results are thrown away[1], the timeout does nothing but waste time, so there's no reason to try to find a lower value that still works. For reference on my system: # Ran 909 tests, 116 skipped, 119 failed. python hash seed: 2052473208 real 151m44.322s user 0m0.077s sys 0m0.046s [1] I thought that I wrote a bug for this, but search isn't finding it.
Fri, 04 Oct 2024 01:29:45 -0400 run-tests: bump the minimum python to 3.8
Matt Harbison <matt_harbison@yahoo.com> [Fri, 04 Oct 2024 01:29:45 -0400] rev 51987
run-tests: bump the minimum python to 3.8 Presumably this was an oversight when hg was updated to 3.8.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 tip