Wed, 29 May 2019 09:59:35 -0400 testparseutil: stop extracting using std* streams as bytes on py3
Augie Fackler <augie@google.com> [Wed, 29 May 2019 09:59:35 -0400] rev 42409
testparseutil: stop extracting using std* streams as bytes on py3 This is no longer required due to other cleanups in our linting tools. Differential Revision: https://phab.mercurial-scm.org/D6455
Wed, 29 May 2019 09:56:27 -0400 tests: sort some imports that were previously missed
Augie Fackler <augie@google.com> [Wed, 29 May 2019 09:56:27 -0400] rev 42408
tests: sort some imports that were previously missed I'm a little unclear why the import checker didn't catch this before, but when I fixed it to work in Python 3 this failure started showing up. Sigh. Differential Revision: https://phab.mercurial-scm.org/D6454
Wed, 29 May 2019 09:55:35 -0400 contrib: fix import-checker to operate on str instead of bytes
Augie Fackler <augie@google.com> [Wed, 29 May 2019 09:55:35 -0400] rev 42407
contrib: fix import-checker to operate on str instead of bytes I believe this is fallout from other Python 3 cleanups, and our code linting tools are now leaning towards operating on str and not bytes. I don't feel strongly, so I've just restored this tool to working on Python 3. Differential Revision: https://phab.mercurial-scm.org/D6453
Tue, 28 May 2019 16:12:11 -0700 verify: use self._err not self.err, it changed in 7eaf4b1ac2a3
Kyle Lippincott <spectral@google.com> [Tue, 28 May 2019 16:12:11 -0700] rev 42406
verify: use self._err not self.err, it changed in 7eaf4b1ac2a3 Differential Revision: https://phab.mercurial-scm.org/D6451
Tue, 28 May 2019 23:22:46 -0700 tests: make run-tests exit non-zero if there are "errors"
Kyle Lippincott <spectral@google.com> [Tue, 28 May 2019 23:22:46 -0700] rev 42405
tests: make run-tests exit non-zero if there are "errors" Previously, if there was an error such as a broken .t file that caused run-tests.py to encounter an exception during parsing, the test would be considered in an "errored" state, which is separate from "failed". The check for whether to exit non-zero or not was based entirely on whether there were any tests in a "failed" state, so if there was only an error, run-tests would exit with 0. Our test infrastructure would then consider the test as passing, causing us to have some tests with false negatives that have gone undetected for a few weeks now. Differential Revision: https://phab.mercurial-scm.org/D6452
Thu, 23 May 2019 18:15:08 +0200 perf: add a `perfhelper-mergecopies` command
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 18:15:08 +0200] rev 42404
perf: add a `perfhelper-mergecopies` command This command gather data that are useful to pick argument for `perfmergecopies`.
Thu, 23 May 2019 14:48:02 +0200 perf: add a new `perfmergecopies` command
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 14:48:02 +0200] rev 42403
perf: add a new `perfmergecopies` command This command benchmark calls to `mercurial.copies.mergecopies`
Thu, 23 May 2019 14:02:01 +0200 perf: factor selection of revisions involved in the merge out
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 14:02:01 +0200] rev 42402
perf: factor selection of revisions involved in the merge out We will introduce more performance command around merge. As a first step we factor out pieces of `perfmergecalculate` that can be reused.
Thu, 23 May 2019 13:49:31 +0200 perf: allow to specify the base of the merge in perfmergecalculate
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 13:49:31 +0200] rev 42401
perf: allow to specify the base of the merge in perfmergecalculate We can now test the rebase case.
Thu, 23 May 2019 11:19:48 +0200 perf: add a --from flag to perfmergecalculate
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 11:19:48 +0200] rev 42400
perf: add a --from flag to perfmergecalculate Before this change, `perfmergecalculate` was always benchmarking the merge of the working copy with another revision. We can now benchmark the `mergecalculate` call for any arbitrary pair of revision.
Tue, 28 May 2019 09:57:53 -0400 merge with stable
Augie Fackler <augie@google.com> [Tue, 28 May 2019 09:57:53 -0400] rev 42399
merge with stable
Sat, 25 May 2019 19:49:44 +0300 py3: fix test-narrow* which started failing because of recent changes
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 25 May 2019 19:49:44 +0300] rev 42398
py3: fix test-narrow* which started failing because of recent changes #skip-blame because just r'' prefix Differential Revision: https://phab.mercurial-scm.org/D6447
Sat, 11 May 2019 00:06:06 -0700 tests: add test for {file_mods}, {file_adds}, {file_dels} on merge commit
Martin von Zweigbergk <martinvonz@google.com> [Sat, 11 May 2019 00:06:06 -0700] rev 42397
tests: add test for {file_mods}, {file_adds}, {file_dels} on merge commit Differential Revision: https://phab.mercurial-scm.org/D6368
Thu, 18 Apr 2019 13:34:20 -0700 context: add ctx.files{modified,added,removed}() methods
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 13:34:20 -0700] rev 42396
context: add ctx.files{modified,added,removed}() methods Changeset-centric copy tracing is currently very slow because it often reads manifests. One place it needs the manifest is in _chain(), where it removes a copy X->Y if Y has subsequently gotten removed. I want to speed that up by keeping track directly in the changeset of which files are removed in the changeset. These methods will be similar to ctx.p[12]copies() in that way: they will either read from the changeset or calculate the information from the manifests otherwise. Note that these are different from ctx.{modified,added,removed}() on merge commits. Those functions always compare to p1, but the new ones compare to both parents. filesadded() means "file does not exist in either parent but exists now", filesremoved() means "file existed in either parent but does not exist now", and filesmodified() means "file existed in either parent and still exists". The set of files in ctx.files() is the union of the files from the three new functions (and the three new ones are all disjoint sets). Also note that uncommitted merges are weird as usual. The invariant mentioned above still holds, but the functions compare to p1 (and are thus identical to the existing methods). Differential Revision: https://phab.mercurial-scm.org/D6367
Thu, 09 May 2019 15:09:07 -0700 copies: split up _chain() in naive chaining and filtering steps
Martin von Zweigbergk <martinvonz@google.com> [Thu, 09 May 2019 15:09:07 -0700] rev 42395
copies: split up _chain() in naive chaining and filtering steps The function now has two clearly defined steps. The first step is the actual chaining. This step is very cheap. The second step is filtering out invalid copies. This step is expensive. For changeset-centric copy tracing, I want to do the filtering step only at the end. This patch prepares for that. Differential Revision: https://phab.mercurial-scm.org/D6418
Fri, 24 May 2019 09:24:47 -0700 relnotes: document changed behavior of ui.origbackuppath pointing to file
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 May 2019 09:24:47 -0700] rev 42394
relnotes: document changed behavior of ui.origbackuppath pointing to file Differential Revision: https://phab.mercurial-scm.org/D6446
Sat, 11 May 2019 00:17:42 -0700 templatekw: move showfileadds() close to showfile{mods,dels}()
Martin von Zweigbergk <martinvonz@google.com> [Sat, 11 May 2019 00:17:42 -0700] rev 42393
templatekw: move showfileadds() close to showfile{mods,dels}() Differential Revision: https://phab.mercurial-scm.org/D6370
Fri, 24 May 2019 15:38:50 +0300 py3: use range() instead of xrange()
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 24 May 2019 15:38:50 +0300] rev 42392
py3: use range() instead of xrange() The latter does not exist on Python 3. This makes test-contrib-perf.t pass on Python 3 again. Differential Revision: https://phab.mercurial-scm.org/D6443
Fri, 24 May 2019 15:59:59 +0300 narrow: move heads close to common as they are closely related
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 24 May 2019 15:59:59 +0300] rev 42391
narrow: move heads close to common as they are closely related Differential Revision: https://phab.mercurial-scm.org/D6445
Fri, 24 May 2019 15:57:00 +0300 narrow: pass binary nodeids to generateellipsesbundle2()
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 24 May 2019 15:57:00 +0300] rev 42390
narrow: pass binary nodeids to generateellipsesbundle2() We generally work with binary nodeids and it's should be expected that new function gets the nodeids in binary form already. Differential Revision: https://phab.mercurial-scm.org/D6444
Fri, 24 May 2019 12:33:46 +0200 match: stabilize _rootsdirsandparents doctest
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 24 May 2019 12:33:46 +0200] rev 42389
match: stabilize _rootsdirsandparents doctest Changeset c4b8f8637d7a tried to stabilize some matcher test by using a set. This did not work because the set order is not stable. To fix it, we post process the result to display a sorted version of the set.
Tue, 21 May 2019 05:32:14 +0530 narrow: factor out logic to build ellipses related b2parts in separate fn
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 21 May 2019 05:32:14 +0530] rev 42388
narrow: factor out logic to build ellipses related b2parts in separate fn This will help us switch more cleanly to using wireprotocol commands instead of using exchange.pull() which exchanges more things then required. Differential Revision: https://phab.mercurial-scm.org/D6435
Tue, 21 May 2019 04:49:18 +0530 narrow: remove unrequired compat code for old versions of hg
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 21 May 2019 04:49:18 +0530] rev 42387
narrow: remove unrequired compat code for old versions of hg As the comment says, that if is only required for servers having hg version 3.1 and 3.2. Any client connecting having hg 3.1 or 3.2 locally and trying to use narrow should already be broken taking in account the changes which have been done since narrow moved to core. Differential Revision: https://phab.mercurial-scm.org/D6434
Thu, 23 May 2019 19:05:39 +0200 perf: make sure to explicitly disable any profiler after the first iteration
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 19:05:39 +0200] rev 42386
perf: make sure to explicitly disable any profiler after the first iteration The current code work, because of some edge behavior of the `profile` class. We make it explicit that the profiler is not in effect more than once.
Wed, 22 May 2019 16:20:34 -0700 test: add missing 'cd ..' to test case
Danny Hooper <hooper@google.com> [Wed, 22 May 2019 16:20:34 -0700] rev 42385
test: add missing 'cd ..' to test case Differential Revision: https://phab.mercurial-scm.org/D6439
Wed, 22 May 2019 14:16:44 -0700 match: remove an obsolete comment about util.finddirs()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 May 2019 14:16:44 -0700] rev 42384
match: remove an obsolete comment about util.finddirs() Obsolete since 8e55c0c642c (util: make util.dirs() and util.finddirs() include root directory (API), 2017-05-16). Differential Revision: https://phab.mercurial-scm.org/D6433
Wed, 22 May 2019 13:58:05 -0700 match: de-flake test-doctest.py by not depending on util.dirs() order
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 May 2019 13:58:05 -0700] rev 42383
match: de-flake test-doctest.py by not depending on util.dirs() order util.dirs() yields directories in arbitrary order, which has made test-doctest.py flaky. I think they have been flaky since d8e55c0c642c (util: make util.dirs() and util.finddirs() include root directory (API), 2017-05-16). Before that commit, I think util.dirs() would return at most one entry, so there was only one iteration order. This patch fixes the problem by making _rootsdirsandparents() return a set (whose __str__() is defined to be in sorted order, I believe). The only caller wanted a set anyway. Differential Revision: https://phab.mercurial-scm.org/D6432
Tue, 21 May 2019 15:26:48 +0200 perf: add an option to profile the benchmark section
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 May 2019 15:26:48 +0200] rev 42382
perf: add an option to profile the benchmark section Running a perf command with --profile gather data for the whole command execution, including setup and cleanup. This can significantly alter the data. To work around this we introduce a new option, it trigger the profiling of only one iteration of the benchmarked section.
Tue, 21 May 2019 15:08:06 +0200 perf: add a `pre-run` option
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 May 2019 15:08:06 +0200] rev 42381
perf: add a `pre-run` option sometimes, the initial run is necessary to warm some cache that are not relevant for the current measurement. We add a new `perf.pre-run` option to specify a number of run of the benchmark logic that will happens before measurement are taken.
Mon, 20 May 2019 18:09:41 -0700 narrow: consider empty commits to be "inside the narrow spec" for templates
Danny Hooper <hooper@google.com> [Mon, 20 May 2019 18:09:41 -0700] rev 42380
narrow: consider empty commits to be "inside the narrow spec" for templates It doesn't seem useful to exclude them, or harmful to include them. Users writing log templates using outsidenarrow as a predicate might consider it unexpected if their locally created empty drafts are treated as if they contained something outside the clone. Differential Revision: https://phab.mercurial-scm.org/D6414
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip