Mercurial: Changelog

chg: respect XDG_RUNTIME_DIR $XDG_RUNTIME_DIR [1] is a better place for user daemons. Let's use it and fallback to $TMPDIR. After this patch, chg will try socket paths in the following order: 1. $CHGSOCKNAME 2. $XDG_RUNTIME_DIR/chg/server 3. ${TMPDIR:-tmp}/chg$UID/server [1]: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

chg: make "get default sockdir" a separate method The logic to get a default socket directory will become longer in the next patch. So let's move it out.

chg: handle connect failure before errno gets overridden This patch moves the error handling logic up so that errno after connect won't be overridden.

py3: have a bytes version of shlex.split() shlex.split() only accepts unicodes on Python 3. After this patch we will be using pycompat.shlexsplit(). This patch also replaces existing occurences of shlex.split with pycompat.shlexsplit.

chg: support long socket path This patch replaces UNIX_PATH_MAX (108) with PATH_MAX (4096) so we can have long unix path.

chg: remove sockdirfd See the previous patch for the reason.

chg: let hgc_open support long path "sizeof(sun_path)" is too small. Use the chdir trick to support long socket path, like "mercurial.util.bindunixsocket". It's useful for cases where TMPDIR is long. Modern OS X rewrites TMPDIR to a long value. And we probably want to use XDG_RUNTIME_DIR [2] for Linux. The approach is a bit different from the previous plan, where we will have hgc_openat and pass cmdserveropts.sockdirfd to it. That's because the current change is easier: chg has to pass a full path to "hg" as the "--address" parameter. There is no "--address-basename" or "--address-dirfd" flags. The next patch will remove "sockdirfd". Note: It'd be nice if we can use a native "connectat" implementation. However, that's not available everywhere. Some platform (namely FreeBSD) does support it, but the implementation has bugs so it cannot be used [2]. [1]: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html [2]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-April/082892.html