Wed, 03 Oct 2018 13:59:19 +0300 py3: whitelist another passing tests caught by buildbot
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 03 Oct 2018 13:59:19 +0300] rev 39988
py3: whitelist another passing tests caught by buildbot I this indygreg recent patches made this test pass on Python 3. So thanks to him! Differential Revision: https://phab.mercurial-scm.org/D4848
Wed, 03 Oct 2018 13:55:51 +0300 manifest: remove an unused variable caught by pyflakes
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 03 Oct 2018 13:55:51 +0300] rev 39987
manifest: remove an unused variable caught by pyflakes Uses of todel were removed in D4843 (19103e68a698). This patch will make buildbots green again. Differential Revision: https://phab.mercurial-scm.org/D4847
Tue, 02 Oct 2018 22:40:01 -0400 setup: ignore message about disabling 3rd party extensions because of version
Matt Harbison <matt_harbison@yahoo.com> [Tue, 02 Oct 2018 22:40:01 -0400] rev 39986
setup: ignore message about disabling 3rd party extensions because of version I started getting into a bind recently when switching between py2 and py3 because switching requires a `make clean`, which kills __version__.py. But then when running `make local`, it picks up the local hg.exe (MSYS seems to prefix $PATH with '.'), which doesn't know its version. That causes it to emit a warning about needing at least 4.3 to load evolve, which caused setup.py to fail saying there is no working hg executable to figure out the version. If we can ignore general extension import failures, we should be able to ignore this too.
Tue, 02 Oct 2018 09:11:18 -0700 narrow: avoid overwriting a variable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 02 Oct 2018 09:11:18 -0700] rev 39985
narrow: avoid overwriting a variable I don't like to overwrite variables, especially not with a different type (because it makes it harder to explain what the variable is for, and, therefore, to name it well). Differential Revision: https://phab.mercurial-scm.org/D4846
Thu, 27 Sep 2018 20:16:48 -0700 treemanifests: remove _loadalllazy in _diff()
spectral <spectral@google.com> [Thu, 27 Sep 2018 20:16:48 -0700] rev 39984
treemanifests: remove _loadalllazy in _diff() The benchmarks below use a similar setup as in ee7ee0c516ca and my other recent commits. Yes, in some cases this runs in literally 5% of the time it previously took. before = a6f8ab53 diff --git: repo | N | T | before (mean +- stdev) | after (mean +- stdev) | % of before ------+---+---+------------------------+-----------------------+------------ m-u | | | 1.301 s +- 0.004 s | 1.309 s +- 0.012 s | 100.6% m-u | | x | 1.303 s +- 0.009 s | 1.302 s +- 0.006 s | 99.9% m-u | x | | 1.308 s +- 0.006 s | 1.309 s +- 0.007 s | 100.1% m-u | x | x | 85.7 ms +- 0.6 ms | 86.0 ms +- 0.3 ms | 100.4% l-d-r | | | 197.5 ms +- 0.7 ms | 197.8 ms +- 2.2 ms | 100.2% l-d-r | | x | 199.4 ms +- 0.6 ms | 199.3 ms +- 0.9 ms | 99.9% l-d-r | x | | 86.1 ms +- 0.5 ms | 85.8 ms +- 0.9 ms | 99.7% l-d-r | x | x | 64.4 ms +- 0.4 ms | 64.4 ms +- 0.3 ms | 100.0% diff -c . --git: repo | N | T | before (mean +- stdev) | after (mean +- stdev) | % of before ------+---+---+------------------------+-----------------------+------------ m-u | | | 236.7 ms +- 1.1 ms | 236.5 ms +- 1.3 ms | 99.9% m-u | | x | 158.7 ms +- 1.0 ms | 128.0 ms +- 1.0 ms | 80.7% <-- m-u | x | | 239.7 ms +- 1.8 ms | 238.1 ms +- 1.5 ms | 99.3% m-u | x | x | 132.4 ms +- 0.9 ms | 132.3 ms +- 0.6 ms | 99.9% l-d-r | | | 81.8 ms +- 0.4 ms | 81.8 ms +- 0.3 ms | 100.0% l-d-r | | x | 3.894 s +- 0.017 s | 193.6 ms +- 0.4 ms | 5.0% <-- l-d-r | x | | 106.9 ms +- 0.4 ms | 106.6 ms +- 0.3 ms | 99.7% l-d-r | x | x | 182.7 ms +- 0.8 ms | 183.3 ms +- 0.9 ms | 100.3% rebase -r . --keep -d .^^: repo | N | T | before (mean +- stdev) | after (mean +- stdev) | % of before ------+---+---+------------------------+-----------------------+------------ m-u | | | 5.615 s +- 0.109 s | 5.562 s +- 0.015 s | 99.1% m-u | | x | 5.701 s +- 0.027 s | 5.715 s +- 0.023 s | 100.2% m-u | x | | 5.572 s +- 0.128 s | 5.613 s +- 0.182 s | 100.7% m-u | x | x | 633.3 ms +- 28.7 ms | 636.2 ms +- 13.8 ms | 100.5% l-d-r | | | 666.4 ms +- 17.0 ms | 658.5 ms +- 9.3 ms | 98.8% l-d-r | | x | 6.520 s +- 0.070 s | 6.505 s +- 0.026 s | 99.8% l-d-r | x | | 279.0 ms +- 13.0 ms | 276.5 ms +- 4.7 ms | 99.1% l-d-r | x | x | 1.636 s +- 0.058 s | 1.657 s +- 0.014 s | 101.3% status --change . --copies: repo | N | T | before (mean +- stdev) | after (mean +- stdev) | % of before ------+---+---+------------------------+-----------------------+------------ m-u | | | 218.6 ms +- 1.4 ms | 217.9 ms +- 1.5 ms | 99.7% m-u | | x | 138.5 ms +- 0.4 ms | 108.4 ms +- 0.2 ms | 78.3% <-- m-u | x | | 220.1 ms +- 1.3 ms | 219.7 ms +- 1.5 ms | 99.8% m-u | x | x | 113.2 ms +- 0.4 ms | 112.4 ms +- 0.8 ms | 99.3% l-d-r | | | 80.2 ms +- 0.3 ms | 80.6 ms +- 0.6 ms | 100.5% l-d-r | | x | 3.899 s +- 0.020 s | 194.8 ms +- 4.0 ms | 5.0% <-- l-d-r | x | | 83.4 ms +- 0.8 ms | 83.2 ms +- 0.2 ms | 99.8% l-d-r | x | x | 732.2 ms +- 4.3 ms | 194.9 ms +- 1.0 ms | 26.6% <-- status --copies: repo | N | T | before (mean +- stdev) | after (mean +- stdev) | % of before ------+---+---+------------------------+-----------------------+------------ m-u | | | 1.917 s +- 0.005 s | 1.914 s +- 0.004 s | 99.8% m-u | | x | 1.909 s +- 0.012 s | 1.934 s +- 0.004 s | 101.3% m-u | x | | 1.915 s +- 0.005 s | 1.904 s +- 0.004 s | 99.4% m-u | x | x | 94.8 ms +- 0.3 ms | 94.7 ms +- 0.2 ms | 99.9% l-d-r | | | 593.9 ms +- 1.2 ms | 594.6 ms +- 9.4 ms | 100.1% l-d-r | | x | 595.2 ms +- 3.8 ms | 597.2 ms +- 2.6 ms | 100.3% l-d-r | x | | 182.5 ms +- 1.6 ms | 182.1 ms +- 0.6 ms | 99.8% l-d-r | x | x | 149.6 ms +- 0.9 ms | 149.1 ms +- 0.8 ms | 99.7% update $rev^; ~/src/hg/hg{hg}/hg update $rev: repo | N | T | before (mean +- stdev) | after (mean +- stdev) | % of before ------+---+---+------------------------+-----------------------+------------ m-u | | | 3.121 s +- 0.007 s | 3.129 s +- 0.012 s | 100.3% m-u | | x | 2.972 s +- 0.011 s | 2.981 s +- 0.012 s | 100.3% m-u | x | | 3.144 s +- 0.014 s | 3.141 s +- 0.011 s | 99.9% m-u | x | x | 312.2 ms +- 2.4 ms | 312.3 ms +- 2.1 ms | 100.0% l-d-r | | | 444.4 ms +- 4.3 ms | 446.9 ms +- 5.3 ms | 100.6% l-d-r | | x | 9.159 s +- 0.069 s | 9.182 s +- 0.040 s | 100.3% l-d-r | x | | 254.6 ms +- 1.6 ms | 255.2 ms +- 1.6 ms | 100.2% l-d-r | x | x | 1.525 s +- 0.007 s | 1.577 s +- 0.007 s | 103.4% <--? Differential Revision: https://phab.mercurial-scm.org/D4845
Tue, 02 Oct 2018 13:41:00 -0700 treemanifests: skip extraneous check for item before calling _loadlazy
spectral <spectral@google.com> [Tue, 02 Oct 2018 13:41:00 -0700] rev 39983
treemanifests: skip extraneous check for item before calling _loadlazy Differential Revision: https://phab.mercurial-scm.org/D4844
Tue, 02 Oct 2018 13:38:26 -0700 treemanifests: make _loadchildrensetlazy just call _loadlazy
spectral <spectral@google.com> [Tue, 02 Oct 2018 13:38:26 -0700] rev 39982
treemanifests: make _loadchildrensetlazy just call _loadlazy This was suggested on the original review for _loadchildrensetlazy (D4370), it's taken me a while to get to it though. Differential Revision: https://phab.mercurial-scm.org/D4843
Tue, 02 Oct 2018 13:37:12 -0700 treemanifests: make _loadlazy tolerate item not on _lazydirs
spectral <spectral@google.com> [Tue, 02 Oct 2018 13:37:12 -0700] rev 39981
treemanifests: make _loadlazy tolerate item not on _lazydirs I'd like to clean up a few cases where we check for an item in _lazydirs before calling _loadlazy - this will remove an extraneous dict lookup and make it slightly more versatile. Differential Revision: https://phab.mercurial-scm.org/D4842
Wed, 08 Aug 2018 23:17:16 -0700 debugcommands: add a debugindexstats command
Martin von Zweigbergk <martinvonz@google.com> [Wed, 08 Aug 2018 23:17:16 -0700] rev 39980
debugcommands: add a debugindexstats command Someone went through the trouble of recording these stats, so let's make them accessible. Differential Revision: https://phab.mercurial-scm.org/D4832
Mon, 24 Sep 2018 19:23:50 +0900 rust-chg: add main program
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 19:23:50 +0900] rev 39979
rust-chg: add main program It can at least connect to a *running* command server, and execute Mercurial command. No signal handling nor daemon management is implemented yet.
Mon, 24 Sep 2018 19:06:30 +0900 rust-chg: add interface to chdir the server
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 19:06:30 +0900] rev 39978
rust-chg: add interface to chdir the server
Mon, 24 Sep 2018 18:57:54 +0900 rust-chg: add Client extensions to run cHg-specific requests
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 18:57:54 +0900] rev 39977
rust-chg: add Client extensions to run cHg-specific requests This just provides a nicer way to issue command-server requests.
Mon, 24 Sep 2018 18:33:46 +0900 rust-chg: port basic socket path handling from cHg of C
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 18:33:46 +0900] rev 39976
rust-chg: port basic socket path handling from cHg of C This is basically modeled after setcmdserveropts() of chg.c.
Mon, 24 Sep 2018 18:21:10 +0900 rust-chg: add state machine to handle "runcommand" request with cHg extension
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 18:21:10 +0900] rev 39975
rust-chg: add state machine to handle "runcommand" request with cHg extension This is modeled after tokio-hglib's RunCommand state to support the "S" channel message.
Mon, 24 Sep 2018 18:18:35 +0900 rust-chg: add callback to handle pager and shell command requests
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 18:18:35 +0900] rev 39974
rust-chg: add callback to handle pager and shell command requests This could be inlined into the ChgRunCommand state to be introduced by the next patch, but it seemed good to separate any user interactions from the IPC code.
Sat, 29 Sep 2018 21:59:07 +0900 rust-chg: add low-level function to set pager fd blocking
Yuya Nishihara <yuya@tcha.org> [Sat, 29 Sep 2018 21:59:07 +0900] rev 39973
rust-chg: add low-level function to set pager fd blocking This is necessary because the server expects stdout/stderr to be blocking, whereas we'll use async library to spawn pager, which makes pipes unblocking.
Mon, 24 Sep 2018 16:59:12 +0900 rust-chg: add future that handles "attachio" request
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 16:59:12 +0900] rev 39972
rust-chg: add future that handles "attachio" request This is the sequence to send client-side stdio and pager stdin to the server.
Mon, 24 Sep 2018 16:33:24 +0900 rust-chg: add parser for request messages sent to "S" channel
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 16:33:24 +0900] rev 39971
rust-chg: add parser for request messages sent to "S" channel The data structure is documented at chgserver.py:channeledsystem().
Mon, 24 Sep 2018 16:22:03 +0900 rust-chg: add wrapper around C function
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 16:22:03 +0900] rev 39970
rust-chg: add wrapper around C function
Mon, 24 Sep 2018 16:14:35 +0900 rust-chg: add function to send fds via domain socket
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 16:14:35 +0900] rev 39969
rust-chg: add function to send fds via domain socket As a beginning, I wrote some C. It's extracted from attachio() of contrib/chg/hgclient.c. Maybe it could be rewritten in Rust by using the libc (and/or nix) crates, but doing that wouldn't be trivial as the code depends on CMSG_*() macros. IMO, using C is better here.
Mon, 24 Sep 2018 15:57:28 +0900 rust-chg: update dependencies
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 15:57:28 +0900] rev 39968
rust-chg: update dependencies
Mon, 24 Sep 2018 15:54:18 +0900 rust-chg: add project skeleton
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 15:54:18 +0900] rev 39967
rust-chg: add project skeleton This directory will host the reimplementation of cHg in Rust. It will use Tokio [1], and tokio-hglib [2] which I wrote for an oxidized CHg, no idea if there's such carbon bonding in nature btw. [1]: https://tokio.rs/ [2]: https://bitbucket.org/yuja/tokio-hglib/ The reasoning for depending on Tokio is that it will allow us to handle Unix signals in a safer way. Well, I believed that until I found a weird function, handlestopsignal(), in cHg codebase. It resends the same signal to the same process by temporarily masking the handler, which can't be inherently async. So the signal handlers will stay in C, which means there isn't actually much reason to write async code right now, other than I've already done most of the async stuff, and slightly easier pager handling. The reasoning for the rewrite is that it will eventually be possible to port server-side config validation back to the client side, which will reduce the complexity of the current daemon management. It will also encourage us to write frontend library (e.g. command line and config parsers) in Rust. The license is GPL2+ because it's likely to include derived work from the cHg of C. The rust/chg crate is excluded from the root workspace as it's unclear how the whole rust packages should be laid out. That can be revisited later.
Fri, 28 Sep 2018 12:56:57 -0700 narrow: move copies overrides to core
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Sep 2018 12:56:57 -0700] rev 39966
narrow: move copies overrides to core The copies overrides seems to have been a little complicated just by not being in core. When moved to core, it becomes trivial (at least I think these overrides have the same effect). Differential Revision: https://phab.mercurial-scm.org/D4825
Sun, 30 Sep 2018 18:45:16 +0300 narrow: pass old includes and excludes to _widen()
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 30 Sep 2018 18:45:16 +0300] rev 39965
narrow: pass old includes and excludes to _widen() In future patches we will need to pass them in the widen wireprotocol command which we are building. Differential Revision: https://phab.mercurial-scm.org/D4812
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 +10000 tip