Mon, 07 Oct 2024 21:48:36 -0400 tests: stabilize `test-split-legacy-inline-changelog.t` on Windows
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Oct 2024 21:48:36 -0400] rev 51990
tests: stabilize `test-split-legacy-inline-changelog.t` on Windows The `tar` command is unable to process "C:\path\to\foo.tar" style paths, which is how `$TESTDIR` is constructed. It also didn't work with `$TESTDIR_FORWARD_SLASH`- both failed with: tar: Cannot connect to C: resolve failed [128] But `cat` can handle it if the path is quoted, and `tar` can read from stdin.
Mon, 07 Oct 2024 19:11:54 -0400 tests: stabilize `test-largefiles-cache.t` on Windows
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Oct 2024 19:11:54 -0400] rev 51989
tests: stabilize `test-largefiles-cache.t` on Windows The `undo.backup.dirstate.bck` was created by `hg commit -m 'add largefile'` at line 18, and deleted in the conditional block by `hg push -q http://localhost:$HGPORT/` at line 138. That's... surprising, but probably not harmful, and can be debugged from Linux if it is a problem. This was showing up in `find src/.hg/largefiles/* | grep -E "(dirstate|$hash)"`.
Mon, 07 Oct 2024 18:33:45 -0400 tests: stabilize `test-journal.t` on Windows
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Oct 2024 18:33:45 -0400] rev 51988
tests: stabilize `test-journal.t` on Windows The file in these lines are double quoted, but single quoted on other platforms. Not sure why, other than `cmd.exe` doesn't recognize single quotes. But it's a cosmetic difference, so glob over it and move on.
Mon, 07 Oct 2024 18:26:41 -0400 tests: stabilize `test-clonebundles.t` on Windows
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Oct 2024 18:26:41 -0400] rev 51987
tests: stabilize `test-clonebundles.t` on Windows The `remote: {foo,bar}` lines were different because `echo` in MSYS uses `\r\n`. I couldn't make it work with the previous echoing of individual lines, changing the internal `echo` to `printf "foo\n"`, because that output as "foon". This works on Linux and Windows, so I'm not thinking too hard about it.
Mon, 07 Oct 2024 17:26:31 -0400 tests: cleanup some special casing of `seq` emitting '\r\n'
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Oct 2024 17:26:31 -0400] rev 51986
tests: cleanup some special casing of `seq` emitting '\r\n' My guess is these predate the commit referenced in the previous commit.
Mon, 07 Oct 2024 16:20:07 -0400 tests: force `seq` to print with '\n' EOL
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Oct 2024 16:20:07 -0400] rev 51985
tests: force `seq` to print with '\n' EOL It looks like consistent EOL is the reason for 0605726179a0, but now on py3, `print()` uses the platform EOL without regard to binary mode. The tests mostly use this to loop over a sequence of number in the shell, but there are a handful that redirect output to a file. Specifically, this fixes Windows runs of `test-bundle2-multiple-changegroups.t`, but there may be other tests this fixes. Some other `tests/*.py` files also set binary mode on stdout, but they also write bytes directly to `sys.stdout.buffer`. I'm not doing that here because PyCharm flags these write calls for passing bytes instead of str (PyCharm is likely wrong, but possibly confused because the code falls back to `sys.stdout` if there is no `.buffer` attribute), and it's annoying.
Mon, 07 Oct 2024 15:48:06 -0400 tests: stabilize `test-bundle-phase-internal.t` on Windows
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Oct 2024 15:48:06 -0400] rev 51984
tests: stabilize `test-bundle-phase-internal.t` on Windows This is a silly difference, and we control the Windows side of things from mercurial/windows.py:195. I'll swap and quote the values to be like `no-windows` at some point, but I suspect this exception output would appear elsewhere, and don't feel like waiting for a 2h+ test run to find all of them.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 tip