dirstate: add docstring for invalidate
This always confuses me, and we already have a docstring on
localrepo.invalidatedirstate.
tests: add missing parens in test-obsolete-bundle-strip.t
The "(not ${revs})" was missing parens around ${revs}, so when revs
was "A + B", it became "(not A + B)" when actually "(not (A + B))" was
intended. Fixing that leads to some more testing of strip.
Similarly, the parens were missing in "${revs}::", making it "A + B::"
instead of "(A + B)::". Thanks to Yuya for noticing this part. This
did not affect any existing tests.
test-clonebundles: conditionalize output for Windows
This was the fallout from
9d6031df42c8 (on stable). Now that individual lines
can be conditionalized, it seems better to be explicit, rather than mash all of
this into one regex. "getaddrinfo failed" was added in
4e566f513fd8 to support
Windows.
killdaemons: close pid file before killing processes
With #serve enabled on Windows, I was getting occasional stacktraces like this:
Errored test-hgweb-json.t: Traceback (most recent call last):
File "./run-tests.py", line 724, in run
self.tearDown()
File "./run-tests.py", line 805, in tearDown
killdaemons(entry)
File "./run-tests.py", line 540, in killdaemons
logfn=vlog)
File "...\tests\killdaemons.py", line 94, in killdaemons
os.unlink(pidfile)
WindowsError: [Error 32] The process cannot access the file because it is
being used by another process: '...\\hgtests.zmpqj3\\child80\\daemon.pids'
Adrian suggested using util.posixfile, which works. However, the 'mercurial'
package isn't in sys.path when invoking run-tests.py, and it isn't clear that
hacking[1] it in is a good thing (especially for test-run-tests.t, which uses an
installation in a temp folder).
I tried using ProcessMonitor to figure out what the other process is, but that
monitoring slows things down to such a degree that the issue doesn't occur. I
was ready to blame the virus scanner, but it happens without that too.
Looking at the code, I don't see anything that would have the pid file open.
But I was able to get through about 20 full test runs without an issue with this
minor change, whereas before it was pretty certain to hit this at least once in
two or three runs.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-May/097907.html
win32: drop a py26 daemonizing hack
I'm not sure what the referenced hang specifically was, but the whole test suite
(with #serve) still runs on python 2.7.13. Aside from no longer prepending
"cmd.exe /c", this backs out
ca6aa8362f33.
I'm trying to track down a rare failure of TerminateProcess() with an access
error, and I've seen random extra python processes hanging around after running
tests sometimes, so this might help.
However,
e48cb1c7a902 forces this change. Since the pid object is no longer
converted to a string, the cmd.exe pid was being saved instead of the hg pid,
and none of the daemons were being killed.