Mon, 31 Jul 2017 14:54:08 -0700 tests: demonstrate that failed "hg ci -A" updates dirstate (issue5645) stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 31 Jul 2017 14:54:08 -0700] rev 33616
tests: demonstrate that failed "hg ci -A" updates dirstate (issue5645) Differential Revision: https://phab.mercurial-scm.org/D203
Mon, 31 Jul 2017 16:32:01 -0700 tests: fix test-flagprocessor.t flakiness stable
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
Mon, 31 Jul 2017 16:40:31 -0700 tests: clarify that duplicate flag processors is not an error stable
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
Tue, 01 Aug 2017 01:27:32 +0900 tests: avoid unexpected result at invocation of *.py file on Windows stable
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().
Mon, 31 Jul 2017 13:16:34 +0900 tests: use pdiff instead of diff for portability stable
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.
Mon, 31 Jul 2017 13:10:19 +0900 tests: make pdiff return appropriate exit code at comparison of files stable
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
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip