Added tag 0.3 for changeset ed0d352a85b9
debian, setup: bump version
debian: split packages into chg executable and server extension

Because Mercurial 3.7 will be shipped with the chgserver extension, we'll
need a way to install only the chg executable.
debian: adjust .hgignore rules for recent version of debuild
merge default into stable (compatible with hg 3.2 to 3.6)
chgserver: fix exception on copying attributes of chgui

I got "AttributeError: 'chgui' object has no attribute '_csystem'" if cwd had
a repository. Because ui attributes are dropped after uisetup(), chgui should
not assume that src has _csystem.

This bug was introduced at 49f64e4c6b19.
chgserver: use modern exception syntax
chgserver: use error.Abort which is the recent convention of Mercurial
chgserver: bump testedwith version to include 3.6-rc
chgserver: send HG variable via system() request

It seems I failed to copy that line by 64ad9c76a56e.
cmdserver: reset buffering policy at attachio only once

This allows a pager to inherit the buffering policy of tty. See hg 62c5e937f477
for details.
cmdserver: reset buffering policy of files obtained from ui, not stdio

8bd7ae41b8f0 changed "attachio" to not touch stdio. So this should do the
same.
hgclient: show debug messages sent from server if enabled

If cmdserver.log is set to "-", server log will be sent via 'd' channel.
chgserver: send cwd and environment variables via system() request
util: add helper to run shell command with environment variables and cwd
chgserver: reintroduce 'S' channel to propagate system() request to client

The system channel was removed at 4cb1439fe387 because the server can
communicate with the tty. But it goes crazy on SIGTSTP (aka Ctrl-Z).

Because the child process is not owned by the client but by the server,
the server of the same process group receives SIGSTOP, leaving the client
tty active. Therefore, all subsequent requests are stalled.

I have no idea how to solve this problem at server side, so I decided to
reintroduce the system channel.
chg: wait until command server process started by client

Before this patch, a temporary lock file was created by the parent hg process
and the daemon process was spawned by it. Because we want to use the lock file
of known name, we call "hg serve --daemon-pipefds" directly and waits for the
lock deletion.

This should avoid race where more than one clients try to start cmdserver
processes assuming that they were the first client.
chg: add helper to wait until lock file is deleted by server
chg: add helper to make lock file during startup of server process

It will be used to avoid startup race.
chg: just try to unlink dead socket and ignore ENOENT

We don't need the extra access() call.
Next