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
Thu, 02 Feb 2017 10:01:00 +0100 debugcommands: move 'debugrebuildfncache' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 10:01:00 +0100] rev 30949
debugcommands: move 'debugrebuildfncache' in the new module
Thu, 02 Feb 2017 10:00:26 +0100 debugcommands: move 'debugrebuilddirstate' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 10:00:26 +0100] rev 30948
debugcommands: move 'debugrebuilddirstate' in the new module
Thu, 02 Feb 2017 09:59:47 +0100 debugcommands: move 'debugpvec' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 09:59:47 +0100] rev 30947
debugcommands: move 'debugpvec' in the new module
Wed, 01 Feb 2017 17:48:30 +0100 debugcommands: move 'debugpushkey' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 17:48:30 +0100] rev 30946
debugcommands: move 'debugpushkey' in the new module
Sun, 12 Feb 2017 03:06:38 -0800 ui: remove urllib2 from being imported early
Kyle Lippincott <spectral@google.com> [Sun, 12 Feb 2017 03:06:38 -0800] rev 30945
ui: remove urllib2 from being imported early Before this change, urllib2 was brought in when constructing the ui object, and that added ~5ms on my Linux workstation to the hg startup time for every command, bringing the time for 'HGRCPATH=/dev/null hg root' from 46ms to 40ms. Now, we construct a single proxy object per initial ui creation (so that if the ui is copied they share the object), but defer the actual instantiation of it and the import of urllib2 until it's needed. # no-check-commit
Mon, 06 Feb 2017 23:57:32 -0500 tests: switch "this command isn't paged" example to id
Augie Fackler <augie@google.com> [Mon, 06 Feb 2017 23:57:32 -0500] rev 30944
tests: switch "this command isn't paged" example to id I'm about to enable pager support in summary.
Tue, 07 Feb 2017 17:08:41 -0500 tests: update test-i18n.t to not depend on the pager extension
Augie Fackler <augie@google.com> [Tue, 07 Feb 2017 17:08:41 -0500] rev 30943
tests: update test-i18n.t to not depend on the pager extension I'm about to mark that extension as deprecated, and that broke this test.
Mon, 06 Feb 2017 21:15:35 -0500 pager: add a test of --pager=no functionality
Augie Fackler <augie@google.com> [Mon, 06 Feb 2017 21:15:35 -0500] rev 30942
pager: add a test of --pager=no functionality I'm about to upend the pager universe, but I would like to not regress anything.
Tue, 07 Feb 2017 17:33:35 +0100 hg: allow usage of XDG_CONFIG_HOME/hg/hgrc
David Demelier <demelier.david@gmail.com> [Tue, 07 Feb 2017 17:33:35 +0100] rev 30941
hg: allow usage of XDG_CONFIG_HOME/hg/hgrc Modern applications must use the following paths to store configuration files: - $XDG_CONFIG_HOME/hg/hgrc, - $HOME/.config/hg/hgrc (if XDG_CONFIG_HOME is unset or not absolute). For backward compatibility, ~/.hgrc is still created if no hgrc exist using hg config --edit. See https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Wed, 01 Feb 2017 17:47:35 +0100 debugcommands: move 'debugpathcomplete' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 17:47:35 +0100] rev 30940
debugcommands: move 'debugpathcomplete' in the new module
Wed, 01 Feb 2017 17:46:21 +0100 debugcommands: move 'debugobsolete' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 17:46:21 +0100] rev 30939
debugcommands: move 'debugobsolete' in the new module
Wed, 01 Feb 2017 17:42:49 +0100 debugcommands: move 'debuglocks' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 17:42:49 +0100] rev 30938
debugcommands: move 'debuglocks' in the new module
Wed, 01 Feb 2017 17:41:12 +0100 debugcommands: move 'debugnamecomplete' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 17:41:12 +0100] rev 30937
debugcommands: move 'debugnamecomplete' in the new module
Wed, 01 Feb 2017 17:40:20 +0100 debugcommands: move 'debugmergestate' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 17:40:20 +0100] rev 30936
debugcommands: move 'debugmergestate' in the new module
Wed, 01 Feb 2017 17:39:31 +0100 debugcommands: move 'debuglabelcomplete' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 17:39:31 +0100] rev 30935
debugcommands: move 'debuglabelcomplete' in the new module
Mon, 13 Feb 2017 20:47:41 -0800 dispatch: start profiling earlier
Bryan O'Sullivan <bryano@fb.com> [Mon, 13 Feb 2017 20:47:41 -0800] rev 30934
dispatch: start profiling earlier This makes it possible to profile extension loading and setup, which takes a substantial fraction of overall execution time for fast commands. (99% of this commit is simply changes of indentation to reflect the hoisting of the two calls to maybeprofile to a single one that happens earlier.) # no-check-commit
Mon, 13 Feb 2017 20:44:20 -0800 dispatch: move detection of profiling earlier during startup
Bryan O'Sullivan <bryano@fb.com> [Mon, 13 Feb 2017 20:44:20 -0800] rev 30933
dispatch: move detection of profiling earlier during startup
Mon, 13 Feb 2017 21:00:50 -0800 ui: fix configwith doctest
Jun Wu <quark@fb.com> [Mon, 13 Feb 2017 21:00:50 -0800] rev 30932
ui: fix configwith doctest 4.2 cannot be expressed with IEEE floating point losslessly, and could cause test failure on some platform: File ".../mercurial/ui.py", line 414, in mercurial.ui.ui.configwith Failed example: u.configwith(float, s, 'float2') Expected: -4.2 Got: -4.2000000000000002 This patch fixes that by changing the number to 4.25, which can be expressed by the binary number 100.01.
Tue, 14 Feb 2017 01:52:16 +0530 test-bdiff: move import inside the function to avoid test failure
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 14 Feb 2017 01:52:16 +0530] rev 30931
test-bdiff: move import inside the function to avoid test failure test-check-module-imports.t fails on some systems where the path of home directories is different than sys.prefix and sys.exec_prefix. Importing silenttestrunner will help avoiding that failure.
Sun, 12 Feb 2017 22:28:09 -0800 profiling: add statprof support for Chrome trace viewer rendering
Bryan O'Sullivan <bryano@fb.com> [Sun, 12 Feb 2017 22:28:09 -0800] rev 30930
profiling: add statprof support for Chrome trace viewer rendering We synthesize function call begin/end events from snapshots, and try (configurably) to eliminate "noisy" stack frames. Example invocation: hg --config profiling.output=$HOME/Desktop/clone.json \ --config profiling.statformat=chrome \ --profile clone https://www.mercurial-scm.org/repo/hg
Sun, 12 Feb 2017 22:20:20 -0800 statprof: allow rendering in the Chrome trace viewer format
Bryan O'Sullivan <bryano@fb.com> [Sun, 12 Feb 2017 22:20:20 -0800] rev 30929
statprof: allow rendering in the Chrome trace viewer format
Sun, 12 Feb 2017 22:16:58 -0800 statprof: add a path simplification function
Bryan O'Sullivan <bryano@fb.com> [Sun, 12 Feb 2017 22:16:58 -0800] rev 30928
statprof: add a path simplification function
Sun, 12 Feb 2017 21:44:55 -0800 ui: rewrite configint in terms of configwith
Bryan O'Sullivan <bryano@fb.com> [Sun, 12 Feb 2017 21:44:55 -0800] rev 30927
ui: rewrite configint in terms of configwith
Sun, 12 Feb 2017 21:40:46 -0800 ui: add a configwith method
Bryan O'Sullivan <bryano@fb.com> [Sun, 12 Feb 2017 21:40:46 -0800] rev 30926
ui: add a configwith method This is a long-overdue generalization of the pattern in configint and configbool.
Mon, 13 Feb 2017 22:15:28 +0530 py3: convert the mode argument of os.fdopen to unicodes (2 of 2)
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 13 Feb 2017 22:15:28 +0530] rev 30925
py3: convert the mode argument of os.fdopen to unicodes (2 of 2)
Mon, 13 Feb 2017 20:06:38 +0530 py3: convert the mode argument of os.fdopen to unicodes (1 of 2)
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 13 Feb 2017 20:06:38 +0530] rev 30924
py3: convert the mode argument of os.fdopen to unicodes (1 of 2) os.fdopen() does not accepts bytes as its second argument which represent the mode in which the file is to be opened. This patch makes sure unicodes are passed in py3 by using pycompat.sysstr().
Thu, 09 Feb 2017 15:20:41 -0500 bugzilla: add a rest api backend (usable with bugzilla 5.0+)
John Mulligan <phlogistonjohn@asynchrono.us> [Thu, 09 Feb 2017 15:20:41 -0500] rev 30923
bugzilla: add a rest api backend (usable with bugzilla 5.0+) Add support for the bugzilla rest api documented at https://wiki.mozilla.org/Bugzilla:REST_API and at https://bugzilla.readthedocs.io/en/latest/ This backend has the following benefits: * It supports the bugzilla api keys so hgrc does not need to contain a user's bugzilla password * Works with Mercurial's "hostfingerprints" support making handling bugzilla instances with self-signed certs easier * Does not use xmlrpc ;-) Adds configuration item 'apikey' in [bugzilla] section. My major concern with these patches is if the approach to HTTP access is the right way for an extension and if hooking into request object and the overriding the get_method to perform PUT requests was a sensible approach. # no-check-commit
Mon, 13 Feb 2017 15:12:17 -0500 keepalive: honor urllib2 style get_method overrides
John Mulligan <phlogistonjohn@asynchrono.us> [Mon, 13 Feb 2017 15:12:17 -0500] rev 30922
keepalive: honor urllib2 style get_method overrides In urllib2 docs and discussions it can be found that in order to make a request other than GET or POST the get_method of a Request object can be overriden. Make Mercurial's internal version of this honor the return value of get_method. Please see the followup patch to the bugzilla extension for the reason for this change. Marking RFC because I'm not entirely sure this is the right way make the HTTP requests.
Fri, 10 Feb 2017 13:56:31 -0800 lock: include Linux pid namespace identifier in prefix
Jun Wu <quark@fb.com> [Fri, 10 Feb 2017 13:56:31 -0800] rev 30921
lock: include Linux pid namespace identifier in prefix Previously, the lock only contains a hostname as an attempt to detect pid namespace difference. However, that's not enough on modern Linux - a single hostname could have different pid namespaces. That means if people run hg inside different PID namespaces with a same UTS namespae, the lock would be broken - an hg proccess in pid namespace A will think the lock having a "random" pid in pid namespace B is "dead" and remove it. This patch solves the above issue by appending an PID namespace identifier of the current process to the lock prefix ("hostname"). It depends on /proc being mounted properly. But I don't think there is a better way to get pid namespace identifier reliably.
Fri, 10 Feb 2017 13:35:21 -0800 lock: move lock._host calculation to a function
Jun Wu <quark@fb.com> [Fri, 10 Feb 2017 13:35:21 -0800] rev 30920
lock: move lock._host calculation to a function This allows customization per platform. See the next patch for why.
Wed, 01 Feb 2017 17:33:46 +0100 debugcommands: move 'debugknown' in the new module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 17:33:46 +0100] rev 30919
debugcommands: move 'debugknown' in the new module
Wed, 01 Feb 2017 17:31:05 +0100 debugcommands: extract debuginstall in the debugcommands module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 17:31:05 +0100] rev 30918
debugcommands: extract debuginstall in the debugcommands module
Mon, 13 Feb 2017 16:35:49 +0100 dispatch: load debugcommand before extension
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 13 Feb 2017 16:35:49 +0100] rev 30917
dispatch: load debugcommand before extension Multiple extension will manipulate commands on load, we need the debug command to be loaded before that point.
Mon, 13 Feb 2017 09:44:16 -0800 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 13 Feb 2017 09:44:16 -0800] rev 30916
merge with stable
Mon, 13 Feb 2017 11:43:12 -0800 bundle2: fix assertion that 'compression' hasn't been set stable
Siddharth Agarwal <sid0@fb.com> [Mon, 13 Feb 2017 11:43:12 -0800] rev 30915
bundle2: fix assertion that 'compression' hasn't been set `n.lower()` will return `compression`, not `Compression`.
Fri, 10 Feb 2017 18:20:58 +0100 wireproto: properly report server Abort during 'getbundle' stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 18:20:58 +0100] rev 30914
wireproto: properly report server Abort during 'getbundle' Previously Abort raised during 'getbundle' call poorly reported (HTTP-500 for http, some scary messages for ssh). Abort error have been properly reported for "push" for a long time, there is not reason to be different for 'getbundle'. We properly catch such error and report them back the best way available. For bundle, we issue a valid bundle2 reply (as expected by the client) with an 'error:abort' part. With bundle1 we do as best as we can depending of http or ssh.
Fri, 10 Feb 2017 18:17:20 +0100 getbundle: cleanly handle remote abort during getbundle stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 18:17:20 +0100] rev 30913
getbundle: cleanly handle remote abort during getbundle bundle2 allow the server to report error explicitly. This was initially implemented for push but there is not reason to not use it for pull too. This changeset add logic similar to the one in 'unbundle' to the client side of 'getbundle'. That logic make sure the error is properly reported as "remote". This will allow the server side of getbundle to send clean "Abort" message in the next changeset.
Fri, 10 Feb 2017 18:06:08 +0100 bundle1: fix bundle1-denied reporting for pull over ssh stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 18:06:08 +0100] rev 30912
bundle1: fix bundle1-denied reporting for pull over ssh Changeset b288fb2724bf introduced a config option to have the server deny pull using bundle1. The original protocol has not really been design to allow that kind of error reporting so some hack was used. It turned the hack only works on HTTP and that ssh server hangs forever when this is used. After further digging, there is no way to report the error in a unified way. Using `ooberror` freeze ssh and raising 'Abort' makes HTTP return a HTTP-500 without further details. So with sadness we implement a version that dispatch according to the protocol used. Now the error is properly reported, but we still have ungraceful abort after that. The protocol do not allow anything better to happen using bundle1.
Fri, 10 Feb 2017 18:06:12 +0100 bundle-tests: operate from outside a repository stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 18:06:12 +0100] rev 30911
bundle-tests: operate from outside a repository We are about to add a test for ssh pull/cloning being denied because of bundle1 usage. For this, it is cleaner to not operate from the clone using http. So we update the test beforehand for clarity. This is more churns that what I'm happy to see on stable, but the rests of the series is worth it in my opinion.
Fri, 10 Feb 2017 17:56:52 +0100 bundle1: display server abort hint during unbundle stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 17:56:52 +0100] rev 30910
bundle1: display server abort hint during unbundle The code was printing the abort message but not the hint. This is now fixed.
Fri, 10 Feb 2017 17:56:59 +0100 bundle1: fix bundle1-denied reporting for push over ssh stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 17:56:59 +0100] rev 30909
bundle1: fix bundle1-denied reporting for push over ssh Changeset b288fb2724bf introduced a config option to have the server deny push using bundle1. The original protocol has not really be design to allow such kind of error reporting so some hack was used. It turned the hack only works on HTTP and that ssh wire peer hangs forever when the same hack is used. After further digging, there is no way to report the error in a unified way. Using 'ooberror' freeze ssh and raising 'Abort' makes HTTP return a HTTP500 without further details. So with sadness we implement a version that dispatch according to the protocol used. We also add a test for pushing over ssh to make sure we won't regress in the future. That test show that the hint is missing, this is another bug fixed in the next changeset.
Fri, 10 Feb 2017 17:56:47 +0100 bundle2: keep hint close to the primary message when remote abort stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 17:56:47 +0100] rev 30908
bundle2: keep hint close to the primary message when remote abort The remote hint message was ignored when reporting the remote error and passed to the local generic abort error. I think I might initially have tried to avoid reimplementing logic controlling the hint display depending of the verbosity level. However, first, there does not seems to have such verbosity related logic and second the resulting was wrong as the primary error and the hint were split apart. We now properly print the hint as remote output.
Sun, 12 Feb 2017 02:23:33 +0900 misc: update year in copyright lines stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 12 Feb 2017 02:23:33 +0900] rev 30907
misc: update year in copyright lines This patch also makes some expected output lines in tests glob-ed for persistence of them. BTW, files below aren't yet changed in 2017, but this patch also updates copyright of them, because: - mercurial/help/hg.1.txt almost all of "man hg" output comes from online help of hg command, and is already changed in 2017 - mercurial/help/hgignore.5.txt - mercurial/help/hgrc.5 "copyright 2005-201X Matt Mackall" in them mentions about copyright of Mercurial itself
Mon, 13 Feb 2017 02:31:56 -0800 localrepo: avoid unnecessary sorting
Stanislau Hlebik <stash@fb.com> [Mon, 13 Feb 2017 02:31:56 -0800] rev 30906
localrepo: avoid unnecessary sorting headrevs output already sorted, no need to sort it again.
Mon, 13 Feb 2017 02:26:18 -0800 localrepo: cache self.changelog in local variable
Stanislau Hlebik <stash@fb.com> [Mon, 13 Feb 2017 02:26:18 -0800] rev 30905
localrepo: cache self.changelog in local variable Repeated self.changelog lookups can incur overhead. Let's cache it in the separate variable.
Tue, 07 Feb 2017 13:11:30 -0800 destutil: remove dead code about non-linear updates
Martin von Zweigbergk <martinvonz@google.com> [Tue, 07 Feb 2017 13:11:30 -0800] rev 30904
destutil: remove dead code about non-linear updates IIUC, the non-linear updates no longer happen by default since 6b1fc09c699a (update: change default destination to tipmost descendant (issue4673) (BC), 2016-02-02), and it was only if they happened by default that we used to error out, so there is no longer a need to handle this case.
Thu, 09 Feb 2017 09:55:31 -0800 update: fix typo/stale comment to match code
Martin von Zweigbergk <martinvonz@google.com> [Thu, 09 Feb 2017 09:55:31 -0800] rev 30903
update: fix typo/stale comment to match code The comment about "obsolete.background" seems to have been about obsolete.foreground ever since it was introduced in a59e575c6ff8 (update: allow dirty update to foreground (successors), 2013-04-16), so let's change it.
Wed, 08 Feb 2017 23:03:33 -0800 merge: remove unused handling of default destination in merge.update()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 08 Feb 2017 23:03:33 -0800] rev 30902
merge: remove unused handling of default destination in merge.update() As far as I can tell, all the callers of merge.update() have been migrated over to use destutil to find the default destination when the revision was not specified. So it's time to delete the code for handling a node value of None. Let's add an assertion that node is not None, so any extensions relying on it will not silently misbehave.
Wed, 08 Feb 2017 14:49:37 -0800 update: localize logic around which ancestor to use
Martin von Zweigbergk <martinvonz@google.com> [Wed, 08 Feb 2017 14:49:37 -0800] rev 30901
update: localize logic around which ancestor to use The merge code works by applying the changes between an ancestor and the working copy onto the destination. To achieve an update, it sets the ancestor to be the parent of the working copy. To achieve a clean update (update -C), it sets the ancestor to be the working copy itself (so there are no changes to carry over). The logic for this was spread out a bit. Let's move it all to one place so it's easier to follow the reason for it. Also add some documentation.
Wed, 08 Feb 2017 22:12:27 -0800 tests: add test for updating to null revision
Martin von Zweigbergk <martinvonz@google.com> [Wed, 08 Feb 2017 22:12:27 -0800] rev 30900
tests: add test for updating to null revision While working on merge.py, I realized that we don't (as far as I could tell) have any tests for updating to the null revision with a dirty working copy. This adds some simple tests for that.
Fri, 10 Feb 2017 15:26:03 -0800 import: mention "stdin" (abbreviated) and add example
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Feb 2017 15:26:03 -0800] rev 30899
import: mention "stdin" (abbreviated) and add example I actually didn't even think it was possible because I searched the help text for "stdin", and didn't even think of searching for "standard input". Let's mention the abbreviated form too to help others like me. (When importing from stdin, we actually print a message saying "applying patch from stdin".) This patch also adds an example showing how to import from stdin.
Thu, 09 Feb 2017 09:32:25 -0800 merge: print status message before launching external merge tool
Martin von Zweigbergk <martinvonz@google.com> [Thu, 09 Feb 2017 09:32:25 -0800] rev 30898
merge: print status message before launching external merge tool It seems somewhat common that people run into a merge conflict and don't notice the launched merge tool, and instead they think hg just hung. Let's print a message for each file that we launch a GUI merge tool for.
Wed, 08 Feb 2017 07:44:10 -0800 pager: exit cleanly on SIGPIPE (BC)
Simon Farnsworth <simonfar@fb.com> [Wed, 08 Feb 2017 07:44:10 -0800] rev 30897
pager: exit cleanly on SIGPIPE (BC) Changeset aaa751585325 removes SIGPIPE handling completely. This is wrong, as it means that Mercurial does not exit when the pager does. Instead, raise SignalInterrupt when SIGPIPE happens with a pager attached, to trigger the normal exit path. This will cause "killed!" to be printed to stderr (hence the BC warning), but in the normal pager use case (where the pager gets both stderr and stdout), this message is lost as we only get SIGPIPE when the pager quits.
(0) -30000 -10000 -3000 -1000 -300 -100 -96 +96 +100 +300 +1000 +3000 +10000 tip