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.
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.
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.
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.
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().
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 16:22:03 +0900] rev 39970
rust-chg: add wrapper around C function
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.
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 15:57:28 +0900] rev 39968
rust-chg: update dependencies
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.
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