Wed, 22 Aug 2018 13:57:01 +0900 filemerge: make capability check for internal tools ignore merge-tools section
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 22 Aug 2018 13:57:01 +0900] rev 39266
filemerge: make capability check for internal tools ignore merge-tools section This is follow up of 4d7b11877dd0. Before this patch, capability check of internal merge tools falls back to _toolbool(), which examines configurations in "merge-tools" section. But "hg help config" explicitly says that "merge-tools" section configures external merge tools. Therefore, this patch makes capability check for internal tools in hascapability() always ignore configurations in merge-tools section. In this patch, command line configurations below are added at tests in tests/test-merge-tools.t, in order to confirm that explicit configuration is intentionally ignored at tool selection. --config merge-tools.:INTERNAL_TOOL.CAPABILITY=true
Fri, 24 Aug 2018 22:21:04 -0700 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Aug 2018 22:21:04 -0700] rev 39265
merge with stable
Fri, 24 Aug 2018 18:21:55 -0700 scmutil: avoid quadratic membership testing (issue5969) stable
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Aug 2018 18:21:55 -0700] rev 39264
scmutil: avoid quadratic membership testing (issue5969) tr.changes['revs'] is an xrange, which has an O(n) __contains__ implementation. The `rev not in newrevs` lookup a few lines below will therefore be O(n^2) if all incoming changesets are public. This issue isn't present on @ because 45e05d39d9ce introduced a custom type implementing an xrange primitive with O(1) contains and switched tr.changes['revs'] to be an instance of that type. We work around the problem on the stable branch by casting the xrange to a set. This is a bit hacky because it requires allocating memory to hold each integer in the range. But we are already holding the full set of pulled revision numbers in memory multiple times (such as in `tr.changes['phases']`). So this is a relatively minor problem. This issue has been present since the phases reporting code was introduced in the 4.7 cycle by eb9835014d20. This change should be reverted/ignored when stable is merged into default. On the mozilla-unified repository with 483492 changesets, `hg clone` time improves substantially: before: 1843.700s user; 29.810s sys after: 461.170s user; 29.360s sys
Wed, 15 Aug 2018 14:41:27 -0700 copies: correctly skip directories that have already been considered
Kyle Lippincott <spectral@google.com> [Wed, 15 Aug 2018 14:41:27 -0700] rev 39263
copies: correctly skip directories that have already been considered Previously, `if dsrc in invalid` would never be true, since we added `dsrc +"/"` to invalid, not `dsrc` itself. Since it's much more common for individual files (not whole directories) to be moved, it seemed cleaner to delay appending the "/" until we know we have some directory moves to actually consider. I haven't benchmarked this, but I imagine this is a mild performance win. Differential Revision: https://phab.mercurial-scm.org/D4284
Fri, 24 Aug 2018 12:55:05 -0700 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Aug 2018 12:55:05 -0700] rev 39262
merge with stable
Fri, 24 Aug 2018 10:19:31 -0700 match: make exactmatcher.visitchildrenset return file children as well
Kyle Lippincott <spectral@google.com> [Fri, 24 Aug 2018 10:19:31 -0700] rev 39261
match: make exactmatcher.visitchildrenset return file children as well Previously, if we had an exactmatcher like ['foo.txt', 'a/bar.txt', 'a/b/c/baz.txt'], we'd get back the following data: '.': {'a'} 'a': {'b'} 'a/b': {'c'} 'a/b/c': 'this' 'a/b/c/d': set() This was incorrect, since visitchildrenset explicitly says not to pay attention to 'foo.txt' and 'a/bar.txt' by not returning them or 'this'. Given the near impossibility of making visitchildrenset reliabbly produce only subdirectories, a previous commit has made it documented and expected that visitchildrenset can return a set containing both files and subdirectories to visit, instead of implying/requiring that visitchildrenset() return 'this' if there are files to visit. This makes the code for exactmatcher match this clarified documentation. Differential Revision: https://phab.mercurial-scm.org/D4365
Thu, 23 Aug 2018 18:04:15 -0700 match: document that visitchildrenset might return files
Kyle Lippincott <spectral@google.com> [Thu, 23 Aug 2018 18:04:15 -0700] rev 39260
match: document that visitchildrenset might return files At least when using includematcher, and probably most matchers, we do not know if a/b/f refers to a file 'f' in a/b, or a subdirectory 'f' in a/b, so most matchers will return {'f'} for visitchildrenset('a/b'). Arguably, all matchers could/should - for exactmatcher, we know that 'f' is a file, but there's no reason to return 'this' for visitchildrenset('a/b') causing code to investigate 'a/b/x', for example. Differential Revision: https://phab.mercurial-scm.org/D4364
Fri, 24 Aug 2018 10:13:27 -0700 util: make timedcm require the label (API)
Augie Fackler <augie@google.com> [Fri, 24 Aug 2018 10:13:27 -0700] rev 39259
util: make timedcm require the label (API) Differential Revision: https://phab.mercurial-scm.org/D4350
Tue, 21 Aug 2018 17:15:51 -0400 cleanup: make all uses of timedcm specify what they're timing
Augie Fackler <augie@google.com> [Tue, 21 Aug 2018 17:15:51 -0400] rev 39258
cleanup: make all uses of timedcm specify what they're timing It's not used in the timing itself, but it's valuable for the trace events we emit. Differential Revision: https://phab.mercurial-scm.org/D4349
Tue, 21 Aug 2018 17:13:35 -0400 util: make timedcm context manager also emit trace events
Augie Fackler <augie@google.com> [Tue, 21 Aug 2018 17:13:35 -0400] rev 39257
util: make timedcm context manager also emit trace events Differential Revision: https://phab.mercurial-scm.org/D4348
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip