This is especially important if extensions that use inotify are enabled,
because it's very easy to hit the inotify max_user_instances limit without
this.
os.listdir returns the files in any order. This has to be sorted.
But when given as argument, the user should be allowed to set any order.
This restores the behaviour before 9848a94e2a.
The test-profile test would fail if the user had HGPROF set to another
profiler in their environment. This fix makes the test independent of
that environment variable.
Reverts the previous attempt to fix this, which was not cross platoform.
When glob lines directly match on windows, "/" (and not "\") was output in the
path on the line. No glob matching is necessary in this case.
The test output will look like this (when 5 tests have passed and no 4 has an
unnecessary glob):
...
Info, unnecessary glob: info about some/thing (glob)
..
This happens when a path with "/" as only glob char is matched on a non windows
platform. (Currently one third of all glob matches.)
The slowdown on windows and the speedup on other os are neglectable.
This makes it possible to fix the seed by using for instance
PYTHONHASHSEED=7 ./run-tests.py ...
This can be very convenient when trying to debug problems that are influenced
by hash values. Try different seed values until you find one that triggers the
bad behaviour and then keep that while debugging.
The value 0 will restore default Python behavior and disable randomization.
In normal test mode stdin is closed and hg is thus not interactive. In --debug
mode stdin is inherited from the running console and to the tests, and hg could
thus wait in prompts when running on Windows.
See http://selenic.com/pipermail/mercurial-devel/2013-January/047548.html .
Instead set ui.interactive=False to make Mercurial non-interactive. Other
commands might still work differently in the --debug environment.
This should solve the problem with hg waiting for input but still make it
possible to add --debugger to hg in a test and run run-tests.py with --debug.
3951b91555f7 caused that some kind of interactive debugging no longer was
possible - such as running hg with --debugger in a test run with run-tests.py
--debug .
Python set and dict iteration order is in principle undefined but usually
'quite stable'. Setting PYTHONHASHSEED=random will make the iteration order
more random in Python 2.6.8 and 2.7.3 and where it has been backported. This
can thus help spot dependencies on undefined behaviour and prevent future
problems.
If interrupted while running with "--jobs N", run-tests asynchronously
spewed a bunch of output and backtraces from both the master and
slave processes, leaving the terminal full of goop. This patch makes
it behave more sensibly.
Before: a symlink for python in BINDIR was sometimes created, but it was never
updated when a different Python was used and it was never removed. An invalid
python could thus be left around and used when testing with --local.
Now: the symlink is removed when wrong and created when necessary.
The mechanism for finding the right name (python or python.exe) also had to be
simplified and made more explicit.
The older approach of trying to copy the python executable into the test
directory was doomed to fail.
There remains one weakness with this approach: if you've run "make local",
tests may pick up the wrong extension DLLs from inside the source tree. I
don't know why this happens.
A reasonable workaround for now is to test either using --local or with
a working directory that does not contain built DLLs.
Previously, we used os.spawnvp, which doesn't exist on Windows, and
isn't needed anyway (the command line begins with an absolute path).
We also need a slightly more convoluted way to wait for processes
without specifying an order on Windows, as it lacks os.wait.
Before a55b74d8de3a all crlf occurrences in test output on Windows were simply
changed to lf. In a55b74d8de3a it was replaced by more clever handling in the
.t test runner ... but the .py runner was forgotten and many .py tests were
failing on Windows.
The crlf/lf replacement is now reintroduced in the py test runner.
After d5471ad04cf6 all \r was stripped from output on Windows, and the places
where a \r explicitly was expected it was accepted that it was missing. Ugly
hack.
Instead we now accept that an extra \r might appear at the end of lines on
Windows. That is more to the point and less ugly.
str.splitlines could not be used in 2d839579ce70, but _now_ we would like to
have lines with other line endings than \n.
Some fine occurences of (esc) markup of \r is replaced with multiple lines
ending with '\r (no-eol) (esc)'. That is no win but also no significant loss.
This change makes it possible to drop filtercr.py - _that_ is a win.
