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.