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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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.
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)
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.
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.
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).
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
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
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!
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.
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
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.
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.
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.
Augie Fackler <augie@google.com> [Wed, 15 Feb 2017 11:22:01 -0500] rev 30965
merge with stable
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.