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
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip