localrepo: disallow share if there is a version mismatch by default
Earlier we used to allow shares which don't use share-safe mechanism to access
repository which uses share-safe mechanism. This defeats the purpose and is bad
behavior. This patch disallows that.
Next patch will introduce a config option to allow that and have clearer
understanding around various options.
Differential Revision: https://phab.mercurial-scm.org/D9784
upgrade: re-read current requirements after taking lock
Since we are writing to repository, it's better to re-read after taking the
lock.
Differential Revision: https://phab.mercurial-scm.org/D9822
upgrade: take lock only for part where it's required
The final config calculation code does not require a lock, only writing it back
does require one.
Differential Revision: https://phab.mercurial-scm.org/D9783
clang-format: reorder includes to appease the formatter
The bad order was introduced in
d0225a22040c.
Differential Revision: https://phab.mercurial-scm.org/D9829
run-tests: catch a Windows specific error when testing for a free socket
I'm not sure why this only happens with py3, but this error code doesn't map to
any of the 3 currently being handled, and kills `run-tests.py` before it can run
any tests when it happens:
OSError: [WinError 10013] An attempt was made to access a socket in a way
forbidden by its access permissions
The documentation[1] says this can happen if another process is bound to the
address with exclusive access. This seems to keep it happy.
[1] https://docs.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2
Differential Revision: https://phab.mercurial-scm.org/D9816
run-tests: work around the Windows firewall popup for server processes
Windows doesn't have a `python3` executable, so
cc0b332ab9fc attempted to work
around the issue by copying the current python to `python3.exe`. That put it in
`_tmpbindir` because of failures in `test-run-tests.t` when using `_bindir`,
which looked like a process was trying to open it to write out a copy while it
was in use. (Interestingly, I couldn't reproduce this running the test by
itself in a loop for a couple of hours, but it happens constantly when running
all tests.) The problem with using `_tmpbindir` is that it is the randomly
generated path for the test run, and instead of Windows Firewall remembering the
executable signature or image hash when allowing the process to open a server
port, it apparently remembers the image path. That means every run will trigger
a popup to allow it, which is bad for firing off a test run and walking away.
I tried to symlink to the python executable, but that currently requires admin
priviledges[1]. This will prompt the first time if the underlying python binary
has never opened a server port, but appears to avoid it on subsequent runs.
[1] https://bugs.python.org/
issue40687
Differential Revision: https://phab.mercurial-scm.org/D9815