Wed, 02 Aug 2017 22:58:38 +0900 test-revlog-raw: close file handles explicitly (issue5644) stable
Yuya Nishihara <yuya@tcha.org> [Wed, 02 Aug 2017 22:58:38 +0900] rev 33625
test-revlog-raw: close file handles explicitly (issue5644)
Wed, 02 Aug 2017 22:04:02 +0900 tests: clear __pycache__ for PyPy compatibility (issue5638) (issue5642) stable
Yuya Nishihara <yuya@tcha.org> [Wed, 02 Aug 2017 22:04:02 +0900] rev 33624
tests: clear __pycache__ for PyPy compatibility (issue5638) (issue5642)
Wed, 02 Aug 2017 22:06:45 +0900 test-extension: glob module name in error message for PyPy stable
Yuya Nishihara <yuya@tcha.org> [Wed, 02 Aug 2017 22:06:45 +0900] rev 33623
test-extension: glob module name in error message for PyPy
Wed, 02 Aug 2017 21:52:22 +0900 rebase: sort collapsed revisions in commit message (issue5643) stable
Yuya Nishihara <yuya@tcha.org> [Wed, 02 Aug 2017 21:52:22 +0900] rev 33622
rebase: sort collapsed revisions in commit message (issue5643) This fixes the test instability.
Wed, 02 Aug 2017 00:02:11 +0900 i18n: use actual filename, in which function is defined, for hg.pot stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 02 Aug 2017 00:02:11 +0900] rev 33621
i18n: use actual filename, in which function is defined, for hg.pot Before this patch, source filename for msgid in hg.pot file becomes incorrect, if a function is defined in file A, but detected in dict in file B, For example, almost all debug* commands are defined in debugcommands.py, but hggettext detects them in "table" of commands.py. Therefore, docstring fragments of debug* commands are marked as "defined in commands.py" in hg.pot file. This is serious problem for translation, because the cost to find out original location of texts increases very much.
Tue, 01 Aug 2017 18:52:52 +0900 ui: enable pager always for explicit --pager=on (issue5580) stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 01 Aug 2017 18:52:52 +0900] rev 33620
ui: enable pager always for explicit --pager=on (issue5580) Before this patch, explicit --pager=on is unintentionally ignored by any disabling factor, even if priority of it is less than --pager=on (e.g. "[ui] paginate = off").
Thu, 20 Jul 2017 01:30:41 -0700 rebase: use one dirstateguard for when using rebase.singletransaction
Durham Goode <durham@fb.com> [Thu, 20 Jul 2017 01:30:41 -0700] rev 33619
rebase: use one dirstateguard for when using rebase.singletransaction This was previously landed as 2519994d25ca but backed out in b63351f6a2 because it broke hooks mid-rebase and caused conflict resolution data loss in the event of unexpected exceptions. This new version adds the behavior back but behind a config flag, since the performance improvement is notable in large repositories. The old commit message was: Recently we switched rebases to run the entire rebase inside a single transaction, which dramatically improved the speed of rebases in repos with large working copies. Let's also move the dirstate into a single dirstateguard to get the same benefits. This let's us avoid serializing the dirstate after each commit. In a large repo, rebasing 27 commits is sped up by about 20%. I believe the test changes are because us touching the dirstate gave the transaction something to actually rollback. (grafted from 9e3dc3a1638b9754b58a0cb26aaa75d868058109) (grafted from 7d38b41d2266d9a02a15c64229fae0da5738dcec) Differential Revision: https://phab.mercurial-scm.org/D135
Mon, 31 Jul 2017 21:47:53 +0900 README: make paragraphs before example code end with "::" for reST syntax stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 31 Jul 2017 21:47:53 +0900] rev 33618
README: make paragraphs before example code end with "::" for reST syntax After this patch, README as reST text can be rendered into HTML more appropriately. This is useful for hosting servers, which render README file as a part of index HTML of its directory (for example, Bitbucket).
Mon, 31 Jul 2017 14:54:57 -0700 commit: don't let failed commit with --addremove update dirstate (issue5645) stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 31 Jul 2017 14:54:57 -0700] rev 33617
commit: don't let failed commit with --addremove update dirstate (issue5645) Differential Revision: https://phab.mercurial-scm.org/D204
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
(0) -30000 -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 +10000 tip