Mon, 24 Dec 2018 15:01:47 +0300 tests: add tests for narrow clone when both sparse and narrow are enabled
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 24 Dec 2018 15:01:47 +0300] rev 41147
tests: add tests for narrow clone when both sparse and narrow are enabled This patch adds tests for doing a narrow clone when client has both sparse and narrow enabled. As shown by this patch, we can see that the narrow clone has sparse enabled which we does not want here. Upcoming patch will fix this. Also while writing tests, I realized we don't have a flag to list the current sparse profile. Differential Revision: https://phab.mercurial-scm.org/D5478
Wed, 09 Jan 2019 20:00:35 -0800 histedit: crashing with a more useful error message on empty defaultrev stable
rdamazio@google.com [Wed, 09 Jan 2019 20:00:35 -0800] rev 41146
histedit: crashing with a more useful error message on empty defaultrev Before this, `hg --config histedit.defaultrev= histedit` would crash with File "destutil.py", line 385, in desthistedit if revs: UnboundLocalError: local variable 'revs' referenced before assignment Differential Revision: https://phab.mercurial-scm.org/D5543
Tue, 08 Jan 2019 00:30:30 -0800 progress: check what type of progress bar to use only once per topic
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 00:30:30 -0800] rev 41145
progress: check what type of progress bar to use only once per topic This seems to have sped up `hg perfprogress` from 1.78 s to 1.41 s. Differential Revision: https://phab.mercurial-scm.org/D5530
Tue, 08 Jan 2019 00:17:41 -0800 progress: split up _print() method in bar-updating and debug-printing
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 00:17:41 -0800] rev 41144
progress: split up _print() method in bar-updating and debug-printing I just thought this was clearer, but it turned out to also simplify the next patch. This seems to have sped up `hg perfprogress` from 1.85 s to 1.78 s. Differential Revision: https://phab.mercurial-scm.org/D5529
Tue, 08 Jan 2019 00:12:08 -0800 progress: move cached debug flag from progress.progbar to scmutil.progress
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 00:12:08 -0800] rev 41143
progress: move cached debug flag from progress.progbar to scmutil.progress It's simpler this way. One possible drawback (and a possisble advantage) is that we now check the debug flag once per topic, so processes that generate new topics all the time will still check the flag frequently. Differential Revision: https://phab.mercurial-scm.org/D5528
Mon, 07 Jan 2019 23:55:26 -0800 progress: write ui.progress() in terms of ui.makeprogress()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 07 Jan 2019 23:55:26 -0800] rev 41142
progress: write ui.progress() in terms of ui.makeprogress() I think ui.makeprogress() should be the preferred interface and we should deprecate ui.progress(). All in-core callers already use ui.makeprogress(). Moving the logic to the scmutil.progress() will let us make further improvements. This seems to have sped up `hg perfprogress` from 1.92 s to 1.85 s, perhaps because we now skip the indirection of updating the progress bar via ui.progress(). Differential Revision: https://phab.mercurial-scm.org/D5527
Tue, 08 Jan 2019 22:07:47 -0800 testrunner: avoid capturing a regex group we don't care about
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 22:07:47 -0800] rev 41141
testrunner: avoid capturing a regex group we don't care about Differential Revision: https://phab.mercurial-scm.org/D5536
Tue, 08 Jan 2019 14:48:05 -0800 remotefilelog: add newlines to ui.log() invocations
Kyle Lippincott <spectral@google.com> [Tue, 08 Jan 2019 14:48:05 -0800] rev 41140
remotefilelog: add newlines to ui.log() invocations The comment at the top of ui.log() says that the message should be a newline-terminated string. When using the blackbox logger, if the string does not end in a newline, the appearance in the file gets quite messy. This sometimes leaves a string with just the newline as the message, these are logged by the blackbox logger just fine. I don't know what other loggers do when logging structured data and a message that is just the newline. Differential Revision: https://phab.mercurial-scm.org/D5533
Tue, 08 Jan 2019 10:31:10 -0500 xdiff: don't attempt to use fuzzer inputs larger than 100k
Augie Fackler <augie@google.com> [Tue, 08 Jan 2019 10:31:10 -0500] rev 41139
xdiff: don't attempt to use fuzzer inputs larger than 100k This is the recommended approach from [0], and limiting the input was suggested in https://github.com/google/oss-fuzz/issues/2076 when discussing our broken coverage build. 0: https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md#custom-libfuzzer-options-for-clusterfuzz Differential Revision: https://phab.mercurial-scm.org/D5525
Tue, 08 Jan 2019 17:52:39 -0800 tests: support passing testcase after .t paths that have path separators
Kyle Lippincott <spectral@google.com> [Tue, 08 Jan 2019 17:52:39 -0800] rev 41138
tests: support passing testcase after .t paths that have path separators This probably could have been implemented by changing the regex above this bit of code, but I wasn't sure if it would end up handling various OSes correctly, so I decided to go with this version instead. Previously: $ tests/run-tests.py tests/test-ssh.t -l running 2 tests using 2 parallel processes .. # Ran 2 tests, 0 skipped, 0 failed. $ tests/run-tests.py tests/test-ssh.t#sshv1 -l running 0 tests using 0 parallel processes # Ran 0 tests, 0 skipped, 0 failed. Now: $ tests/run-tests.py tests/test-ssh.t -l running 2 tests using 2 parallel processes .. # Ran 2 tests, 0 skipped, 0 failed. $ tests/run-tests.py tests/test-ssh.t#sshv1 -l running 1 tests using 1 parallel processes . # Ran 1 tests, 0 skipped, 0 failed. Differential Revision: https://phab.mercurial-scm.org/D5535
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip