Wed, 15 Feb 2017 21:09:00 -0800 dumbhttp: use IPv6 if HGIPV6 is set to 1
Jun Wu <quark@fb.com> [Wed, 15 Feb 2017 21:09:00 -0800] rev 31024
dumbhttp: use IPv6 if HGIPV6 is set to 1 This will fix flaky tests using dumbhttp. The patch was tested on gcc112.fsffrance.org using the following command: ./run-tests.py -j 40 --runs-per-test 120 test-bundle2-remote-changegroup.t
Wed, 15 Feb 2017 21:03:42 -0800 runtests: export HGIPV6 to hint test scripts whether to use IPv6
Jun Wu <quark@fb.com> [Wed, 15 Feb 2017 21:03:42 -0800] rev 31023
runtests: export HGIPV6 to hint test scripts whether to use IPv6 Previously, run-tests.py only exports HGPORT, and scripts in tests do not know if IPv6 should be used. And that breaks scripts like dumbhttp.py which always uses IPv4. This patch makes run-tests.py export HGIPV6, which can help test scripts like dumbhttp.py and tinyproxy.py to decide whether to use IPv6 or not.
Fri, 17 Feb 2017 00:59:09 -0800 runtests: prefer IPv4 to IPv6
Jun Wu <quark@fb.com> [Fri, 17 Feb 2017 00:59:09 -0800] rev 31022
runtests: prefer IPv4 to IPv6 To make IPv6 work, there are multiple areas that need to fix. Before they all get fixed, use IPv4 by default. This should fix tests caused on IPv6 systems.
Fri, 17 Feb 2017 11:08:36 +0100 doc: correct example concerning "hg purge" alias in man page "hgrc.5"
Rainer Woitok <Rainer.Woitok@Gmail.Com> [Fri, 17 Feb 2017 11:08:36 +0100] rev 31021
doc: correct example concerning "hg purge" alias in man page "hgrc.5" The "hg purge" alias as currently described in "hgrc.5" issues a possibly confusing error message like rm: missing operand Try 'rm --help' for more information. if no files are to be purged at all. This patch slightly modifies the example by adding a "-f" option to the "rm" command.
Mon, 06 Feb 2017 23:22:04 -0500 tests: prove that ignore works
Augie Fackler <augie@google.com> [Mon, 06 Feb 2017 23:22:04 -0500] rev 31020
tests: prove that ignore works
Mon, 06 Feb 2017 22:52:47 -0500 annotate: migrate to modern pager API
Augie Fackler <augie@google.com> [Mon, 06 Feb 2017 22:52:47 -0500] rev 31019
annotate: migrate to modern pager API
Mon, 06 Feb 2017 23:55:54 -0500 ui: add a debug print right before we start the pager
Augie Fackler <augie@google.com> [Mon, 06 Feb 2017 23:55:54 -0500] rev 31018
ui: add a debug print right before we start the pager This makes it easier to figure out why a command is getting paginated.
Mon, 06 Feb 2017 23:42:04 -0500 ui: respect historic pager.attend-$COMMAND=no
Augie Fackler <augie@google.com> [Mon, 06 Feb 2017 23:42:04 -0500] rev 31017
ui: respect historic pager.attend-$COMMAND=no I'm on the fence about this behavior, but the user's intent was pretty specific and it's not expensive to support this case.
Mon, 06 Feb 2017 23:45:30 -0500 tests: clean up a bunch of pager testing that is about to be invalidated
Augie Fackler <augie@google.com> [Mon, 06 Feb 2017 23:45:30 -0500] rev 31016
tests: clean up a bunch of pager testing that is about to be invalidated All this attend logic and potential bugs just no longer make sense to test.
Mon, 06 Feb 2017 23:21:45 -0500 ui: add ignore-single-command functionality
Augie Fackler <augie@google.com> [Mon, 06 Feb 2017 23:21:45 -0500] rev 31015
ui: add ignore-single-command functionality This closes the last feature gap other than the attend list from the extension. For now, I'm leaving the attend list in the extension, because I'm unsure it has merit in a world where commands have been updated to take advantage of the modern API.
Wed, 15 Feb 2017 17:48:03 -0500 ui: introduce neverpager() call
Augie Fackler <augie@google.com> [Wed, 15 Feb 2017 17:48:03 -0500] rev 31014
ui: introduce neverpager() call I'm about to add direct paging support to some commands, and as a result we need a way to communicate from the higher layers of dispatch that paging is explicitly disabled.
Wed, 15 Feb 2017 17:47:57 -0500 pager: move more behavior into core
Augie Fackler <augie@google.com> [Wed, 15 Feb 2017 17:47:57 -0500] rev 31013
pager: move more behavior into core This moves the global flag and the --pager=yes logic into core. Only functionality change is that users now always get a --pager flag and can enable the pager via the flag without the extension active. Moving the flag into core exposes a defect in the ro localization, which will have to be corrected later.
Wed, 15 Feb 2017 17:47:51 -0500 pager: move pager-initiating code into core
Augie Fackler <augie@google.com> [Wed, 15 Feb 2017 17:47:51 -0500] rev 31012
pager: move pager-initiating code into core No functionality change. A previous version of this API had a category argument on ui.pager(). As I migrated the commands in core, I couldn't come up with good enough consistency in any categorization scheme so I just scrapped the whole idea. It may be worth revisiting in the future.
Thu, 16 Feb 2017 10:33:59 -0800 test-logtoprocess: use cat to wait for outputs
Jun Wu <quark@fb.com> [Thu, 16 Feb 2017 10:33:59 -0800] rev 31011
test-logtoprocess: use cat to wait for outputs Commands started by logtoprocess are running asynchronously. To be able to test the output, we need to block and wait for the output. The patch uses "| cat" to wait for such "asynchronous" outputs, to make the test more reliable. I have also written a short notice at the top, hopefully people would be aware of the pitfall when changing the test.
(0) -30000 -10000 -3000 -1000 -300 -100 -14 +14 +100 +300 +1000 +3000 +10000 tip