Thu, 16 Feb 2017 00:13:29 -0800 runtests: set web.address to localhost
Jun Wu <quark@fb.com> [Thu, 16 Feb 2017 00:13:29 -0800] rev 31009
runtests: set web.address to localhost Previously, "hg serve" will listen on "", which is not clear which interface it will actually listen on - it could listen on all interfaces (ex. 0.0.0.0 on IPv4). The run-tests.py script only checks "localhost" for available ports. So let's make it the same for "hg serve" by explicitly setting "web.address" to "localhost". This resolves some IPv6 EADDRINUSE errors.
Thu, 16 Feb 2017 09:38:52 -0800 tests: use LOCALIP
Jun Wu <quark@fb.com> [Thu, 16 Feb 2017 09:38:52 -0800] rev 31008
tests: use LOCALIP This patch replaces hardcoded 127.0.0.1 with $LOCALIP in all tests. Till now, the IPv6 series should make tests pass on common IPv6 systems where the local device has the address "::1" and the hostname "localhost" resolves to "::1".
Wed, 15 Feb 2017 23:24:03 -0800 dummyssh: use LOCALIP
Jun Wu <quark@fb.com> [Wed, 15 Feb 2017 23:24:03 -0800] rev 31007
dummyssh: use LOCALIP This patch replaces hard-coded 127.0.0.1 with $LOCALIP in dummyssh.
Thu, 16 Feb 2017 08:01:19 -0800 runtests: export LOCALIP
Jun Wu <quark@fb.com> [Thu, 16 Feb 2017 08:01:19 -0800] rev 31006
runtests: export LOCALIP Previously, tests hard-code local IP address as "127.0.0.1". That won't work for IPv6. This patch exports the $LOCALIP environment variable, which is set to "::1" if we decide to use IPv6.
Wed, 15 Feb 2017 22:53:45 -0800 tinyproxy: use IPv6 if HGIPV6 is set to 1
Jun Wu <quark@fb.com> [Wed, 15 Feb 2017 22:53:45 -0800] rev 31005
tinyproxy: use IPv6 if HGIPV6 is set to 1 This patch makes tinyproxy.py work in IPv6 mode if HGIPV6 is set to 1. This will make test-http-proxy.t pass on IPv6 machines.
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 31004
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 31003
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 31002
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 31001
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 31000
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 30999
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 30998
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 30997
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 30996
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 30995
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 30994
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 30993
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 30992
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 30991
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.
Thu, 16 Feb 2017 23:10:47 -0800 chgserver: move comments in config example
Jun Wu <quark@fb.com> [Thu, 16 Feb 2017 23:10:47 -0800] rev 30990
chgserver: move comments in config example "#" must be the first character of a line to mark the text as comments. So let's change the docstring.
Wed, 15 Feb 2017 19:41:14 -0800 localrepo: move extension loading to a separate method
Jun Wu <quark@fb.com> [Wed, 15 Feb 2017 19:41:14 -0800] rev 30989
localrepo: move extension loading to a separate method The stateful chg plan [1] requires a special repo object, where ideally all side effects caused by loading the repo object could be reverted by just dropping (gabbage collect) the loaded repo object. Currently, that is impossible because repo.__init__ calls "extensions.loadall", which may have unpredictable side-effects that cannot be reverted by dropping the repo object. This patch moves "extensions.loadall" to a separate method, so chg could subclass localrepository and make extensions loading a no-op. [1]: mercurial-scm.org/pipermail/mercurial-devel/2017-February/092547.html
Thu, 16 Feb 2017 17:30:35 +0530 py3: convert the mode argument of os.fdopen to unicodes
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 16 Feb 2017 17:30:35 +0530] rev 30988
py3: convert the mode argument of os.fdopen to unicodes Couple of these from the earlier series got lost while rebasing. So this patch converts them again.
Wed, 15 Feb 2017 16:29:58 -0800 runtests: unindent an "if True" block
Jun Wu <quark@fb.com> [Wed, 15 Feb 2017 16:29:58 -0800] rev 30987
runtests: unindent an "if True" block The block was left to make review easier. This patch unindents it.
Wed, 15 Feb 2017 16:43:27 -0800 runtests: set web.ipv6 if we use IPv6
Jun Wu <quark@fb.com> [Wed, 15 Feb 2017 16:43:27 -0800] rev 30986
runtests: set web.ipv6 if we use IPv6 As explained by the previous patch, we need to set "web.ipv6=True" if we decide to use IPv6. Otherwise "hg serve" will still try to listen on IPv4. This patch makes it so by appending web.ipv6 to "extra configs". This patch was tested in a Linux system with IPv6, by the following steps: 1. Change hgweb/server.py temporarily to write a file if IPv6HTTPServer.__init__ is called. 2. run-tests.py -l --keep-tmpdir test-serve.t 3. Check the generated .hgrc, make sure it sets web.ipv6=1. 4. Check the log file to make sure IPv6HTTPServer.__init__ is called.
Wed, 15 Feb 2017 16:22:22 -0800 runtests: checkportisavailable should only check one family
Jun Wu <quark@fb.com> [Wed, 15 Feb 2017 16:22:22 -0800] rev 30985
runtests: checkportisavailable should only check one family As explained by the previous patch, checkportisavailable() should only check the preferred family - either IPv4 or IPv6, not both. This patch makes it so.
Wed, 15 Feb 2017 16:18:31 -0800 runtests: add a function to test if IPv6 is available
Jun Wu <quark@fb.com> [Wed, 15 Feb 2017 16:18:31 -0800] rev 30984
runtests: add a function to test if IPv6 is available Previously, checkportisavailable returns True if the port is free either on IPv4 or IPv6, but the hg server only uses IPv4 by default. That leads to issues when IPv4 port is not free but the IPv6 one is. To address that, run-tests should stick with either IPv4 or IPv6. This patch adds a function similar to checkportisavailable to test if IPv6 is available, and assigns the result to a variable. The new function was tested in a Linux system script with the following steps: 1. Run "ip addr del ::1/128 dev lo" to delete lo's IPv6 address, Confirm checkipv6available() returns False. 2. Run "ip addr add ::1/128 dev lo" to add back lo's IPv6 address. Confirm checkipv6available() returns True. 3. Start a web server taking the 8000 port. Confirm checkipv6available(8000) is still True.
Wed, 15 Feb 2017 13:34:06 -0800 histedit: log the time taken to read in the commands list
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:34:06 -0800] rev 30983
histedit: log the time taken to read in the commands list If we're being fed an external command list from stdin (histedit --commands -), then the time spent reading stdin is outside our control. Log it.
Wed, 15 Feb 2017 13:34:06 -0800 extdiff: log time spent in external diff program
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:34:06 -0800] rev 30982
extdiff: log time spent in external diff program We can't fix the time external diff programs take to run. Log that duration for us to remove from any stats we gather
Wed, 15 Feb 2017 13:34:06 -0800 crecord: log blocked time waiting for curses input
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:34:06 -0800] rev 30981
crecord: log blocked time waiting for curses input We want to know when we're blocked waiting for the user - log the time spent waiting in the curses keyboard handlers
Wed, 15 Feb 2017 13:38:00 -0800 ui: give editor() a tag of its own
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:38:00 -0800] rev 30980
ui: give editor() a tag of its own We know that calls to ui.editor() always block on the user's configured editor. Use a blocking tag that ensures that we don't see a huge variety of editor options in our logging.
Wed, 15 Feb 2017 13:29:12 -0800 ui: time calls to ui.system
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:29:12 -0800] rev 30979
ui: time calls to ui.system We want to know when we're blocked on ui.system, and why. Allow the user to supply a tag - otherwise we record on an unspecific tag derived from cmd.
Wed, 15 Feb 2017 13:50:06 -0800 ui: log time spent blocked on stdio
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:50:06 -0800] rev 30978
ui: log time spent blocked on stdio We use a wrapper around Mercurial at Facebook that logs key statistics (like elpased time) to our standard performance tooling. This is less useful than it could be, because we currently can't tell when a command is slow because we need to fix Mercurial versus when a command is slow because the user isn't interacting quickly. Teach Mercurial to log the time it spends blocked, so that our tooling can pick it up and submit it with the elapsed time - we can then do the math in our tooling to see if Mercurial is slow, or if the user simply failed to interact. Combining this with the command duration log means that we can ensure that we concentrate performance efforts on the things that bite Facebook users. The perfwrite microbenchmark shifts from: Linux: ! wall 3.213560 comb 0.410000 user 0.350000 sys 0.060000 (best of 4) Mac: ! wall 0.342325 comb 0.180000 user 0.110000 sys 0.070000 (best of 20) before this change to: ! wall 3.478070 comb 0.500000 user 0.420000 sys 0.080000 (best of 3) Mac: ! wall 0.218112 comb 0.220000 user 0.150000 sys 0.070000 (best of 15) showing a small hit in comb time, but firmly in the noise on wall time.
Wed, 15 Feb 2017 13:07:26 -0800 contrib: add a write microbenchmark to perf.py
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:07:26 -0800] rev 30977
contrib: add a write microbenchmark to perf.py I'm adding some performance logging to ui.write - this benchmark lets us confirm that the cost of that logging is acceptably low. At this point, the microbenchmark on Linux over SSH shows: ! wall 3.213560 comb 0.410000 user 0.350000 sys 0.060000 (best of 4) while on the Mac locally, it shows: ! wall 0.342325 comb 0.180000 user 0.110000 sys 0.070000 (best of 20)
Wed, 15 Feb 2017 13:17:45 -0800 ui: provide a mechanism to track and log blocked time
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:17:45 -0800] rev 30976
ui: provide a mechanism to track and log blocked time We want to log the time Mercurial spends trapped in things outside programmatic control. Provide a mechanism to give us both command runtime and as many different sources of blocking as we deem useful.
Wed, 15 Feb 2017 13:17:39 -0800 mercurial: switch to util.timer for all interval timings
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:17:39 -0800] rev 30975
mercurial: switch to util.timer for all interval timings util.timer is now the best available interval timer, at the expense of not having a known epoch. Let's use it whenever the epoch is irrelevant.
Wed, 15 Feb 2017 11:53:59 -0800 util: introduce timer()
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 11:53:59 -0800] rev 30974
util: introduce timer() As documented for timeit.default_timer, there are better timers available for performance measures on some platforms. These timers don't have a set epoch, and thus are only useful for interval measurements, but have higher resolution, and thus get you a better measurement overall. Use the same selection logic as Python's timeit.default_timer. This is a platform clock on Python 2 and early Python 3, and time.perf_counter on Python 3.3 and later (where time.perf_counter is introduced as the best timer to use).
Thu, 22 Dec 2016 02:38:53 +0100 color: move the '_render_effects' function to the core module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 02:38:53 +0100] rev 30973
color: move the '_render_effects' function to the core module
Thu, 22 Dec 2016 02:37:18 +0100 color: move '_effect_str' function into the core module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 02:37:18 +0100] rev 30972
color: move '_effect_str' function into the core module
Thu, 22 Dec 2016 02:34:22 +0100 color: move configstyles into the core module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 02:34:22 +0100] rev 30971
color: move configstyles into the core module The extension is getting thinner as we speak!
Thu, 22 Dec 2016 02:30:03 +0100 color: rework conditional 'valideffect'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 02:30:03 +0100] rev 30970
color: rework conditional 'valideffect' Not very important, but the full conditional is not that hard to follow and having it unified make the function role a bit clearer in my opinion.
Thu, 22 Dec 2016 02:26:50 +0100 color: move 'valideffect' function into the core module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 02:26:50 +0100] rev 30969
color: move 'valideffect' function into the core module
Thu, 22 Dec 2016 02:23:23 +0100 color: move '_terminfo_params' into the core 'color' module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 02:23:23 +0100] rev 30968
color: move '_terminfo_params' into the core 'color' module On step closer to have color in core.
Fri, 18 Nov 2016 18:48:38 +0100 color: move '_effect' mapping into core
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 18 Nov 2016 18:48:38 +0100] rev 30967
color: move '_effect' mapping into core This is the second things we can move into core safely.
Fri, 18 Nov 2016 18:43:39 +0100 color: spread '_effect' values for readability
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 18 Nov 2016 18:43:39 +0100] rev 30966
color: spread '_effect' values for readability We move to our "usual" one value per line style.
Wed, 15 Feb 2017 11:22:01 -0500 merge with stable
Augie Fackler <augie@google.com> [Wed, 15 Feb 2017 11:22:01 -0500] rev 30965
merge with stable
Mon, 13 Feb 2017 15:04:46 -0800 update: clarify that -C and -c are mutually exclusive
Martin von Zweigbergk <martinvonz@google.com> [Mon, 13 Feb 2017 15:04:46 -0800] rev 30964
update: clarify that -C and -c are mutually exclusive This makes it clear in both the synopsis and in the verbose output that -C and -c are mutually exclusive. It also restructures the verbose output a little so it's better prepared for a third option (--merge). This patch also reorders the options to match the flag table.
Mon, 13 Feb 2017 11:58:02 -0800 update: move check for dirty wdir into hg.updatetotally()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 13 Feb 2017 11:58:02 -0800] rev 30963
update: move check for dirty wdir into hg.updatetotally() The function has a "check" parameter that's currently unused, and it makes sense to me to have it honor it. That way other callers than commands.update() could set it if they needed.
Mon, 13 Feb 2017 11:32:09 -0800 destutil: drop now-unused "check" parameter from destupdate()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 13 Feb 2017 11:32:09 -0800] rev 30962
destutil: drop now-unused "check" parameter from destupdate()
Thu, 09 Feb 2017 09:52:32 -0800 destutil: remove duplicate check and leave it to merge.update()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 09 Feb 2017 09:52:32 -0800] rev 30961
destutil: remove duplicate check and leave it to merge.update() The check is done in merge.update() already and the next few patches will add more checks there. Some of the additional checks will need information about the merge that will not be available in destutil. Since commands.postincoming() catches UpdateAbort(), we need to change merge.update() to raise that more specific exception. This goes directly again 45b86dbabbda (destupdate: move the check related to the "clean" logic in the function, 2015-10-05), but it will simplify the next few patches, and we can always move it out again (preferably move, not copy) after if we still think it's better that way.
Wed, 15 Feb 2017 14:49:33 +0800 make: update .PHONY targets
Anton Shestakov <av6@dwimlabs.net> [Wed, 15 Feb 2017 14:49:33 +0800] rev 30960
make: update .PHONY targets
Thu, 02 Feb 2017 10:07:53 +0100 debugcommands: move 'debugwireargs' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 10:07:53 +0100] rev 30959
debugcommands: move 'debugwireargs' in the new module
Thu, 02 Feb 2017 10:07:28 +0100 debugcommands: move 'debugwalk' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 10:07:28 +0100] rev 30958
debugcommands: move 'debugwalk' in the new module
Thu, 02 Feb 2017 10:06:01 +0100 debugcommands: move 'debugtemplate' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 10:06:01 +0100] rev 30957
debugcommands: move 'debugtemplate' in the new module
Thu, 02 Feb 2017 10:05:22 +0100 debugcommands: move 'debugsuccessorssets' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 10:05:22 +0100] rev 30956
debugcommands: move 'debugsuccessorssets' in the new module
Thu, 02 Feb 2017 10:04:55 +0100 debugcommands: move 'debugsub' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 10:04:55 +0100] rev 30955
debugcommands: move 'debugsub' in the new module
Thu, 02 Feb 2017 10:04:34 +0100 debugcommands: move 'debugstate' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 10:04:34 +0100] rev 30954
debugcommands: move 'debugstate' in the new module
Thu, 02 Feb 2017 10:04:02 +0100 debugcommands: move 'debugsetparents' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 10:04:02 +0100] rev 30953
debugcommands: move 'debugsetparents' in the new module
Thu, 02 Feb 2017 10:03:31 +0100 debugcommands: move 'debugrevspec' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 10:03:31 +0100] rev 30952
debugcommands: move 'debugrevspec' in the new module
Thu, 02 Feb 2017 10:02:40 +0100 debugcommands: move 'debugrevlog' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 10:02:40 +0100] rev 30951
debugcommands: move 'debugrevlog' in the new module
Thu, 02 Feb 2017 10:01:54 +0100 debugcommands: move 'debugrename' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 10:01:54 +0100] rev 30950
debugcommands: move 'debugrename' in the new module
(0) -30000 -10000 -3000 -1000 -300 -100 -60 +60 +100 +300 +1000 +3000 +10000 tip