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 39290
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 39289
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 39288
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 39287
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 39286
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 39285
util: make timedcm context manager also emit trace events Differential Revision: https://phab.mercurial-scm.org/D4348
Tue, 21 Aug 2018 15:27:30 -0400 demandimport: instrument python 2 code with trace events
Augie Fackler <augie@google.com> [Tue, 21 Aug 2018 15:27:30 -0400] rev 39284
demandimport: instrument python 2 code with trace events This causes the evaluation of an import in Python 3 to emit some trace data. There's some interesting wrinkles in here, like the fact that before we even hit dispatch we've demand-imported `sys` several times, despite the fact that `sys` was already fully loaded as one of the first few statements in the `hg` script. I don't think that's actually costing us a ton of performance, but it's probably something we should investigate fixing some day. Differential Revision: https://phab.mercurial-scm.org/D4347
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip