Mon, 03 Jul 2017 02:52:39 +0900 tests: add line specific for testing with fsmonitor
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 03 Jul 2017 02:52:39 +0900] rev 33214
tests: add line specific for testing with fsmonitor
Mon, 03 Jul 2017 02:52:39 +0900 tests: make output lines conditional for testing with fsmonitor
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 03 Jul 2017 02:52:39 +0900] rev 33213
tests: make output lines conditional for testing with fsmonitor Repository cloned-bookmark-default and tobundle exist in the working directory of main test repository "repo". We should take care for them, because it is known issue that fsmonitor can't handle nested repositories. These nested repositories are cloned from "repo", and the number of unknown files = files in these repositories (including files under .hg) will be changed easily in the future. But testing with fsmonitor is not ordinary. Therefore, test-bookmarks.t with fsmonitor might be broken silently. This is reason why this patch uses "(glob)" for the number of unknown files in "hg summary" output. BTW, this patch doesn't use .hgignore to make test portable, because .hgignore might cause another issue related to "walk_on_invalidate" configuration of fsmonitor.
Mon, 03 Jul 2017 02:52:39 +0900 tests: add fsmonitor specific output lines at enabling largefiles
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 03 Jul 2017 02:52:39 +0900] rev 33212
tests: add fsmonitor specific output lines at enabling largefiles Temporarily enabling largefiles causes these output lines, only if tests are executed with fsmonitor.
Mon, 03 Jul 2017 21:26:39 -0700 show: document why accidentally quadratic is (probably) acceptable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 03 Jul 2017 21:26:39 -0700] rev 33211
show: document why accidentally quadratic is (probably) acceptable
Mon, 03 Jul 2017 21:18:32 -0700 show: also catch AmbiguousCommand
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 03 Jul 2017 21:18:32 -0700] rev 33210
show: also catch AmbiguousCommand cmdutil.findcmd() can raise this as well. While we'll almost certainly never encounter this in the wild, guard against it regardless.
Mon, 03 Jul 2017 21:12:04 -0700 show: avoid extra list operations
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 03 Jul 2017 21:12:04 -0700] rev 33209
show: avoid extra list operations
Mon, 03 Jul 2017 21:10:48 -0700 show: tweak warning message
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 03 Jul 2017 21:10:48 -0700] rev 33208
show: tweak warning message '.' is "working directory parent" not "working directory."
Fri, 23 Jun 2017 13:49:34 +0200 revlog: add an experimental option to mitigated delta issues (issue5480)
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Jun 2017 13:49:34 +0200] rev 33207
revlog: add an experimental option to mitigated delta issues (issue5480) The general delta heuristic to select a delta do not scale with the number of branch. The delta base is frequently too far away to be able to reuse a chain according to the "distance" criteria. This leads to insertion of larger delta (or even full text) that themselves push the bases for the next delta further away leading to more large deltas and full texts. This full text and frequent recomputation throw Mercurial performance in disarray. For example of a slightly large repository 280 000 files (2 150 000 versions) 430 000 changesets (10 000 topological heads) Number below compares repository with and without the distance criteria: manifest size: with: 21.4 GB without: 0.3 GB store size: with: 28.7 GB without 7.4 GB bundle last 15 00 revisions: with: 800 seconds 971 MB without: 50 seconds 73 MB unbundle time (of the last 15K revisions): with: 1150 seconds (~19 minutes) without: 35 seconds Similar issues has been observed in other repositories. Adding a new option or "feature" on stable is uncommon. However, given that this issues is making Mercurial practically unusable, I'm exceptionally targeting this patch for stable. What is actually needed is a full rework of the delta building and reading logic. However, that will be a longer process and churn not suitable for stable. In the meantime, we introduces a quick and dirty mitigation of this in the 'experimental' config space. The new option introduces a way to set the maximum amount of memory usable to store a diff in memory. This extend the ability for Mercurial to create chains without removing all safe guard regarding memory access. The option should be phased out when core has a more proper solution available. Setting the limit to '0' remove all limits, setting it to '-1' use the default limit (textsize x 4).
Sun, 02 Jul 2017 13:24:23 +0900 tests: use system hg only if changelog or dirstate can't be read
Yuya Nishihara <yuya@tcha.org> [Sun, 02 Jul 2017 13:24:23 +0900] rev 33206
tests: use system hg only if changelog or dirstate can't be read The bundled hg should work flawlessly in most cases. Make it depend on the external installation only if necessary since we can't control the whole environment. This patch doesn't implement the "exit 80" idea proposed by Jun. I don't want to keep the capability checking sync with the actual tests.
Sun, 02 Jul 2017 13:20:28 +0900 tests: restore workaround of obsolete warning from 3c9066ed557c
Yuya Nishihara <yuya@tcha.org> [Sun, 02 Jul 2017 13:20:28 +0900] rev 33205
tests: restore workaround of obsolete warning from 3c9066ed557c It's simple and works well unless you are using third-party extensions that changes the store format.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip