Martin von Zweigbergk <martinvonz@google.com> [Mon, 31 Jul 2017 16:32:01 -0700] rev 33615
tests: fix test-flagprocessor.t flakiness
The test for duplicate flag processors depended on the timestamps
being set in the dirstate to work. If the time between the the
previous failed commit (which would set the timestamp, due to bug
5645) and the attempted commit with the duplicate flag processors was
small enough, it would fail. The failure was caused by a call to
commands.status() early in the commit process. If the dirstate did not
have the timestamp set, it would need to fetch the file content to
compare with. Since two flag processors had been registered, it would
attempted to base64 decode the contents twice, which would of course
fail.
This patch adds a "hg debugrebuilddirstate" to make it deterministic
and also replaces the test case's "hg commit" by simply "hg status",
since that will trigger reading of the contents and thereby use of the
flag processors as noted above.
Differential Revision: https://phab.mercurial-scm.org/D202
Martin von Zweigbergk <martinvonz@google.com> [Mon, 31 Jul 2017 16:40:31 -0700] rev 33614
tests: clarify that duplicate flag processors is not an error
The flag processors test for duplicate processors for a single flag
was misleading because the file from the previous test case caused it
to fail (making the "echo 'this should fail' > file" part
irrelevant). Let's remove the leftover from the previous test case to
make it clear that duplicate flag processors results only in a
warning.
Note that duplicate flag processors would have resulted in a failure
(not just a warning) until
ea1c2eb7abd3 (extensions: catch uisetup and
extsetup failures and don't let them break hg, 2017-06-06). I remember
expressing my concern about ending up with half-loaded extensions. It
would be pretty unfortunate to have double-encoded revlog content
enter a repo, so maybe we should reconsider?
Differential Revision: https://phab.mercurial-scm.org/D201
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 01 Aug 2017 01:27:32 +0900] rev 33613
tests: avoid unexpected result at invocation of *.py file on Windows
Invocation of "diff tool.py" in test-extdiff.t tests whether
shellquote() is applied on specified command as expected.
But direct invocation of "*.py" file might cause unexpected result on
Windows according to suffix binding.
For example, starting IDE, showing dialog to choose program to be
used, and so on. In such case, running test-extdiff.t is easily timed
out.
This patch uses intermediate *.bat file on Windows, to avoid such
unexpected result. Naming that intermediate file as "diff tool.bat" is
enough to test applying shellquote().
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 31 Jul 2017 13:16:34 +0900] rev 33612
tests: use pdiff instead of diff for portability
"diff" command might cause redundant message, "No differences
encountered" on Solaris for example. But suppressing option like "-q"
isn't portable, because POSIX specification doesn't define it.
pdiff script was introduced by
b59ef0c21405 to stabilize output of
standard diff command on each platforms.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 31 Jul 2017 13:10:19 +0900] rev 33611
tests: make pdiff return appropriate exit code at comparison of files
Before this patch, pdiff script returns 0, even if diff is detected.
This issue doesn't cause failure of tests using it, if it is invoked
via extdiff extension, because extdiff itself examines changes between
specified revisions and decides exit code.
BTW, this patch ignores recursive comparison case, because:
- there is no portable way for current while-read based
implementation to return 1 at detecting changes
- it isn't yet needed to replace direct "diff -r" invocation by
pdiff for portability
Augie Fackler <augie@google.com> [Tue, 01 Aug 2017 10:14:25 -0400] rev 33610
merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 31 Jul 2017 12:43:26 -0700] rev 33609
tests: make test-profile.t pass if statprof didn't collect samples
We had the first 3 tests in test-profile.t fail because the output
didn't match. I have not yet confirmed that this was because no
samples were collected, but we shouldn't require samples to be
collected for the test to pass either way.
Differential Revision: https://phab.mercurial-scm.org/D199
Boris Feld <boris.feld@octobus.net> [Thu, 27 Jul 2017 10:52:56 +0200] rev 33608
pypy: fix failing test-devel-warnings.t with Pypy5.6.0
In Pypy 5.6.0, traceback exception classes are not displayed with their full
qualified name.
Instead of displaying mercurial.error.ProgrammingError, Pypy displays
ProgrammingError.
Update the test to support both version.