Gregory Szorc <gregory.szorc@gmail.com> [Mon, 08 Oct 2018 17:06:24 -0700] rev 40123
tests: disable zstd in test
This makes the test pass in pure installs.
Differential Revision: https://phab.mercurial-scm.org/D4913
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 08 Oct 2018 17:20:41 -0700] rev 40122
wireprotov2: remove "compression" from capabilities response
This is not used. And future commits will change how this mechanism
works. Let's remove it.
As a bonus, this fixes some test failures on pure installs (due to
zstd references).
Differential Revision: https://phab.mercurial-scm.org/D4912
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 08 Oct 2018 16:27:40 -0700] rev 40121
zstandard: vendor python-zstandard 0.10.1
This was just released.
The upstream source distribution from PyPI was extracted. Unwanted
files were removed.
The clang-format ignore list was updated to reflect the new source
of files.
setup.py was updated to pass a new argument to python-zstandard's
function for returning an Extension instance. Upstream had to change
to use relative paths because Python 3.7's packaging doesn't
seem to like absolute paths when defining sources, includes, etc.
The default relative path calculation is relative to setup_zstd.py
which is different from the directory of Mercurial's setup.py.
The project contains a vendored copy of zstandard 1.3.6. The old
version was 1.3.4.
The API should be backwards compatible and nothing in core should
need adjusted. However, there is a new "chunker" API that we
may find useful in places where we want to emit compressed chunks
of a fixed size.
There are a pair of bug fixes in 0.10.0 with regards to
compressobj() and decompressobj() when block flushing is used. I
actually found these bugs when introducing these APIs in Mercurial!
But existing Mercurial code is not affected because we don't
perform block flushing.
# no-check-commit because 3rd party code has different style guidelines
Differential Revision: https://phab.mercurial-scm.org/D4911
Yuya Nishihara <yuya@tcha.org> [Tue, 25 Sep 2018 20:55:03 +0900] rev 40120
rust-chg: install signal handlers to forward signals to server
I use sync::Once as a synchronization primitive because it's quite easy
to use, and is good enough to prevent data race in these C functions.
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 22:19:49 +0900] rev 40119
rust-chg: remove SIGCHLD handler which won't work in oxidized chg
Since pager is managed by the Rust part, the C code doesn't know the pager
pid. I could make the Rust part teach the pid to C, but still installing
SIGCHLD handler seems horrible idea since we no longer use handcrafted
low-level process management functions.
Instead, I'm thinking of adding async handler to send SIGPIPE at the exit
of the pager.
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 22:04:57 +0900] rev 40118
rust-chg: extract signal handlers from chg/procutil.c
abortmsgerrno() and debugmsg() are removed, and the public interface instead
returns success/error status. Since signal handlers can't propagate errors,
the result of kill() is just ignored.
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 23:19:49 +0900] rev 40117
help: document about "version" template keywords
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 23:14:21 +0900] rev 40116
help: document about "tags" template keywords
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 23:12:04 +0900] rev 40115
help: document about "status" template keywords
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 23:05:00 +0900] rev 40114
help: document about "resolve" template keywords