Tue, 08 Oct 2024 15:54:59 +0200 module-policy: ignore empty module policy stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Oct 2024 15:54:59 +0200] rev 51957
module-policy: ignore empty module policy This make the variable easier to work with, the empty value is not ambiguous about not wanting to get in the way.
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 51956
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 51955
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 51954
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 51953
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 51952
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 51951
run-tests: bump the minimum python to 3.8 Presumably this was an oversight when hg was updated to 3.8.
Fri, 04 Oct 2024 01:23:31 -0400 tests: stabilize `test-sparse.t` on Windows
Matt Harbison <matt_harbison@yahoo.com> [Fri, 04 Oct 2024 01:23:31 -0400] rev 51950
tests: stabilize `test-sparse.t` on Windows One of the reserved characters for path values is '*', so it can't be used. Fortunately, missing this seems to not get in the way of any other tests, and it is removed shortly after with `rm -r foo*bar`, and the extant 'foo-bar' matches the pattern.
Thu, 03 Oct 2024 21:08:10 -0400 tests: fix a test hang on Windows when setting a debuglock
Matt Harbison <matt_harbison@yahoo.com> [Thu, 03 Oct 2024 21:08:10 -0400] rev 51949
tests: fix a test hang on Windows when setting a debuglock I have no idea why, but running the `hg -R auto-upgrade debuglock --set-lock` command near the end of `test-upgrade-repo.t` hangs the test. It does background the process and `killdaemons.py` runs without error, but control doesn't return to `run-tests.py` until the process is manually killed. I did notice that `$!` in MSYS is *not* the PID of the process that got backgrounded, even when a simple `sleep 60 &` is run in MSYS without the *.t file. When `killdaemons.py` is run manually with the PID in ProcessExplorer, the backgrounded process terminates immediately, and returns control to `run-tests.py`. This looks like it would be a race, but the test waits 10s for the lock file to appear before attempting to kill the process, so there's time. `hg serve` has a `--pid-file` option to write the pid to the file, but this is only a debug command, so I'm not bothering with cluttering the command line.
Thu, 03 Oct 2024 19:49:05 -0400 tests: conditionalize `chmod` usage in `test-upgrade-repo.t`
Matt Harbison <matt_harbison@yahoo.com> [Thu, 03 Oct 2024 19:49:05 -0400] rev 51948
tests: conditionalize `chmod` usage in `test-upgrade-repo.t` While the command itself doesn't error out on Windows, it also doesn't make the filesystem readonly. Therefore the repo gets altered to drop dirstate-v2, and puts it out of sync with that happens on Linux.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 tip