Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Oct 2018 16:44:21 -0700] rev 40128
wireprotov2: handle stream encoding settings frames
Like what we just did for the server reactor, we teach the client
reactor to handle stream encoding settings frames. The code is
very similar.
We define a method on the stream class to handle processing the data
within the decoded frames. However, it doesn't yet do anything useful.
Differential Revision: https://phab.mercurial-scm.org/D4918
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Oct 2018 15:43:21 -0700] rev 40127
wireprotov2: document client reactor actions
We should document these so consumers have an easier life.
Differential Revision: https://phab.mercurial-scm.org/D4917
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Oct 2018 16:26:45 -0700] rev 40126
wireprotov2: handle sender protocol settings frames
We teach the server reactor to handle the optional sender protocol
settings frames, which can only be sent at the beginning of frame
exchange.
Right now, we simply decode the data and record the sender protocol
settings on the server reactor instance: we don't yet do anything
meaningful with the data.
Differential Revision: https://phab.mercurial-scm.org/D4916
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Oct 2018 14:05:16 -0700] rev 40125
wireprotov2: update stream encoding specification
The encoding of data within streams in the frame-based protocol is
not yet defined or implemented. This means that all data in wire
protocol version 2 is currently being sent out raw, without
compression. That's obviously not ideal.
This commit formalizes the beginnings of stream encoding support
in the protocol.
I suspect we'll change behavior substantially in the future. My goal
is to get something landed so we can use compression. We can build
out more robust support later.
Because the frame type ID changed, this is strictly BC. But existing
code wasn't using the frame. I'll bump the framing protocol version
later once code is introduced to use the new frame.
Differential Revision: https://phab.mercurial-scm.org/D4915
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Oct 2018 15:08:42 -0700] rev 40124
cborutil: cast bytearray to bytes
This code didn't like passing in bytearray instances. Let's cast
bytearray to bytes so it works.
Differential Revision: https://phab.mercurial-scm.org/D4914
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
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 23:00:50 +0900] rev 40113
help: document about "paths" template keywords
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 22:56:37 +0900] rev 40112
help: document about "identify" template keywords
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 22:50:12 +0900] rev 40111
help: document about "grep" template keywords
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 17:35:25 +0900] rev 40110
chgserver: catch Abort while parsing early args to shut down cleanly
_loadnewui() calls dispatcher functions, which may raise Abort if unparsable
arguments are passed in. The server should catch such errors and translate
them to the "exit 255" instruction so the client can finish the IPC session
cleanly.
Spotted while porting the chg client to Rust.
Yuya Nishihara <yuya@tcha.org> [Fri, 05 Oct 2018 22:08:37 +0900] rev 40109
chg: upgrade client to use "setumask2" command
No compatibility code is added to the client side, since it's unlikely for
new client to communicate with the old server.
Yuya Nishihara <yuya@tcha.org> [Thu, 04 Oct 2018 23:25:55 +0900] rev 40108
chgserver: add "setumask2" command which uses correct message frame
The first 4 bytes should be a length field, not a value. Spotted while
porting chg functions to the Rust one.
muxator <a.mux@inwind.it> [Tue, 09 Oct 2018 22:29:10 +0200] rev 40107
packaging: "make deb" no longer fails
Release 4.7 rationalized the layout of the build scripts.
Unfortunately, while "make docker-ubuntu-*" and "make docker-debian-*" worked as
expected, "make deb" was broken.
Before this change "make deb" was failing with the following error:
You are not inside a Mercurial repository!
Or, after the latest changes:
You are inside <fullpath>, which is not the root of a Mercurial repository
Moreover, when "make deb" failed, the cleanup routine deleted the wrong
directory (contrib/packaging/debian instead of <reporoot>/debian) resulting in
a corrupted working copy that needed to be hg revert-ed.
After this change the docker targets continue to work, and the deb one is able
to finish.
muxator <a.mux@inwind.it> [Tue, 09 Oct 2018 22:24:38 +0200] rev 40106
packaging: cleanup() did not read the value of $CLEANUP
When the original author put CLEANUP in a conditional statement he was probably
willing to use it to control the "if". This change tries to restore that
behaviour: the "rm" clause is triggered if and only if CLEANUP is defined and
not empty.
muxator <a.mux@inwind.it> [Tue, 09 Oct 2018 22:18:35 +0200] rev 40105
packaging: builddeb's cleanup needs to expand PWD, safely
Single quotes would not expand the variable.