mercurial: Changelog

exewrapper: avoid directly linking against python3X.dll Subsequent code calls `LoadLibrary()` to attempt to load the DLL, but because of this symbol reference, there is an attempt to load the DLL used during the build prior to `_main()` running. This causes the whole process to fail if the DLL isn't in the standard search path. That also means it will never load the DLL for HackableMercurial. (Maybe we should get rid of that for py3, since you can install python for a user without admin rights?) This could also be resolved by calling `GetProcAddress()` on the symbol and dereferencing it, but using the environment variable is consistent with the *.bat file since fc8a5c9ecee0. (The environment variable persists after the interpreter is initialized.) Far more concerning is somehow I've gotten my system into a state where setting the flag causes any output to the pager to be lost (as if it wasn't set at all) in MSYS, cmd.exe, WSL, and PowerShell using py3.9.0, but the environment variable works properly. I'm sure this flag worked on some versions of py3, so I'm not sure what's going on here. This is might be related to init config related changes in 3.8[1], since it works with 3.7.8, but fails with 3.8.1. Somebody who understands encoding issues better than I do should give some thought to if we need to make some changes to our encoding strategy on Windows with py3. With or without the flag/envvar, there is proper output if the command is directly paged by piping to `more.com` (in any environment) or `less` (in MSYS and WSL), or if paging is disabled with `--pager=no`. Legacy mode is required though when Mercurial decides to spin up a pager. [1] https://bugs.python.org/issue41941 Differential Revision: https://phab.mercurial-scm.org/D10756

tests: partially fix test-transaction-rollback-on-revlog-split.t on Windows For whatever reason, the extra space causes different output on Windows: $ printf '% 20d' '1' | xxd - 0000000: 2020 2020 2020 2020 2020 2020 2020 2020 0000010: 2020 2020 31 1 vs WSL: /mnt/c/Users/Matt/hg/tests$ printf '% 20d' '1' | xxd - 00000000: 2020 2020 2020 2020 2020 2020 2020 2020 00000010: 2020 2031 Without the space, they both agree the last word is 2031. There are other failures on Windows that I don't understand that are introduced by 46b828b85eb7 and 18415fc918a1. Differential Revision: https://phab.mercurial-scm.org/D10763

tests: fix test-transaction-safety.t on Windows Mostly this is about `C:\dir\sub` style paths being turned into `C:dirsub` by MSYS, and not being about to execute shell scripts in hooks directly. See also a12819559ccb::9e3979a25bfe. Differential Revision: https://phab.mercurial-scm.org/D10762

docket: move the uid logic in the `revlogutils.docket` module We want to use it for revlog-v2 (& Co), it seems more logical to have the logic lives inside the `docket` file than the `nodemap` file. Differential Revision: https://phab.mercurial-scm.org/D10755

persistent-nodemap: use the intended uuid size I overlooked this in the initial implementation. The format already supporting any uuid size so, nothing horrible should happens. Differential Revision: https://phab.mercurial-scm.org/D10754

persistent-nodemap: add a way to make the picked uid predictable This will make the test less volatile and therefore easier to maintain. I am setting this is for the persistent nodemap docket first, but my target is to use similar logic for the revlogv2 (and co) test. For persisent nodemap, they are too many different in how each test variants (with rust, without rust, etc) needs new uid for this be really useful (right now). However it will be directly useful for the revlogv2 logic. Differential Revision: https://phab.mercurial-scm.org/D10753

run-tests: disable color in 'auto' mode on Windows if stdout is redirected Differential Revision: https://phab.mercurial-scm.org/D10761

run-tests: enable color on Windows In setting up the CI for Windows on heptapod, I noticed it was complaining about color not being enabled because pygments wasn't installed- even though it was. I had initially disabled color on Windows when using Windows 7, because that didn't understand ANSI color codes and made a mess of the output. But now that it's been unsupported for over a year, I don't think we should care about it either. It's admittedly a hack to depend on Mercurial proper to enable color support in the terminal, but I didn't feel like duplicating that code. I'm under the impression that 3rd party stuff is supposed to use this runner in the Mercurial repo instead of using their own copy, so I think it's safe to assume the Mercurial code is available. If it's not, it won't break anything. Differential Revision: https://phab.mercurial-scm.org/D10760