Re: [PATCH] update: remove dead (?) code about non-linear updates

2017-02-08 Thread Martin von Zweigbergk via Mercurial-devel
On Tue, Feb 7, 2017 at 1:29 PM, Martin von Zweigbergk
 wrote:
> # HG changeset patch
> # User Martin von Zweigbergk 
> # Date 1486501890 28800
> #  Tue Feb 07 13:11:30 2017 -0800
> # Node ID 0659349ff46b2d449ceb02fe01b63053d8a43a13
> # Parent  1f51b4658f21bbb797e922d155c1046eddccf91d
> update: remove dead (?) code about non-linear updates

Please ignore this patch. I think I can do it in a clearer way.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] zeroconf: fail nicely on IPv6 only system

2017-02-08 Thread Jun Wu
This does not work if the hardcoded 127.0.0.1 is not known to the system:

sudo ip addr del 127.0.0.1/8 dev lo # on Linux

That could happen if the system is IPv6-only, or only has other addresses in
the 127./8 subnet like 127.0.0.2, or does not have a "lo" device. I think
the pathological environments are not that uncommon with all kinds of
container technologies.

Maybe a better fix is to just skip the test when we detect "dumbip" is not
an IPv4 address.

Excerpts from Simon Farnsworth's message of 2017-02-08 08:10:48 -0800:
> # HG changeset patch
> # User Simon Farnsworth 
> # Date 1486570121 28800
> #  Wed Feb 08 08:08:41 2017 -0800
> # Node ID a847eb00fcfeffce458e11b80ad38d4d4e7a700f
> # Parent  d50cda2a403786836d1f0d5c99401599dc4f43ec
> zeroconf: fail nicely on IPv6 only system
> 
> zeroconf only knows how to deal with IPv4; I develop on a system where the 
> only
> IPv4 address is 127.0.0.1.
> 
> Teach zeroconf to ignore IPv6 addresses when looking for plausible IPv4
> connectivity.
> 
> diff --git a/hgext/zeroconf/__init__.py b/hgext/zeroconf/__init__.py
> --- a/hgext/zeroconf/__init__.py
> +++ b/hgext/zeroconf/__init__.py
> @@ -64,7 +64,9 @@
>  # Generic method, sometimes gives useless results
>  try:
>  dumbip = socket.gethostbyaddr(socket.gethostname())[2][0]
> -if not dumbip.startswith('127.') and ':' not in dumbip:
> +if ':' in dumbip:
> +dumbip = '127.0.0.1'
> +if not dumbip.startswith('127.'):
>  return dumbip
>  except (socket.gaierror, socket.herror):
>  dumbip = '127.0.0.1'
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 2 of 4 RFC] chgcache: implement simple IPC mechanism

2017-02-08 Thread Jun Wu
# HG changeset patch
# User Jun Wu 
# Date 1486601798 28800
#  Wed Feb 08 16:56:38 2017 -0800
# Node ID 8410c4a6703bed4b459cf8d62bd32fdcb1e7
# Parent  138f7ba58a70de9610713b8bd55d1ba0ac468fa6
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 8410c4a670ff
chgcache: implement simple IPC mechanism

We need an inter-process communication mechanism so forked chg workers could
tell the master chg server where the repos are. The IPC mechanism:

  - Could be one-way - workers send messages to the master. Currently
workers won't read from the master.
  - Should be non-blocking on write - workers should not wait for the master
to read content they send.
  - Could lose messages - messages are just some "suggestions" about what to
preload, which could be discarded safely.
  - Better to be blocking on read - if reading is blocking, the master
server could learn what to preload immediately, without polling
periodically.

This patch adds a class using datagram sockets to do the IPC. The choice is
mainly because SOCK_DGRAM prevents incomplete messages from being sent, and
we don't need to deal with message boundaries.

diff --git a/hgext/chgcache.py b/hgext/chgcache.py
--- a/hgext/chgcache.py
+++ b/hgext/chgcache.py
@@ -10,2 +10,56 @@ With this extension installed, Mercurial
 repo objects to further reduce start-up time.
 """
+from __future__ import absolute_import
+
+import socket
+
+class socketipc(object):
+"""A simple IPC mechanism that sets up an unreliable communication channel
+between the master server and (multiple) forked worker processes. The
+forked workers do non-blocking writes, while the master server does
+blocking reads.
+
+To use the object, create it in the master server, read from a thread, and
+write from forked processes:
+
+# pid=1000, master, main thread
+ipc = socketipc()
+
+# pid=1000, master, a background thread
+while True:
+msg = ipc.recv() # blocking
+
+
+# pid=1001, worker
+ipc.send('foo') # non-blocking, silently ignore errors
+
+# pid=1002, worker
+ipc.send('bar') # non-blocking, silently ignore errors
+"""
+
+suffix = b'\0'  # to detect truncated recv()s
+maxsize = 1 << 16  # estimated max packet size for recv()
+
+def __init__(self):
+self._in, self._out = socket.socketpair(socket.AF_UNIX,
+socket.SOCK_DGRAM)
+self._out.setblocking(False)
+
+def send(self, msg):
+"""send msg without blocking. fail silently on errors, ex. msg is too
+long, or the queue is full. msg should not contain '\0'.
+"""
+try:
+return self._out.send(msg + self.suffix)
+except socket.error:
+pass
+
+def recv(self):
+"""receive a complete msg. blocking."""
+while True:
+try:
+msg = self._in.recv(self.maxsize)
+if msg.endswith(self.suffix):
+return msg[:-1]
+except socket.error:
+pass
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 1 of 4 RFC] chgcache: new experimental extension

2017-02-08 Thread Jun Wu
# HG changeset patch
# User Jun Wu 
# Date 1486601732 28800
#  Wed Feb 08 16:55:32 2017 -0800
# Node ID 138f7ba58a70de9610713b8bd55d1ba0ac468fa6
# Parent  a68510b69f413545722c086eaeb840dd5e8305b4
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 138f7ba58a70
chgcache: new experimental extension

This patch starts a new experimental extension - chgcache, which aims to
make chg stateful and be able to preload repo objects like the changelog,
the dirstate, the obsstore etc.

The feature is being developed as a new extension, instead of directly at
core chg, because its APIs and implementation details are still subject to
change.

diff --git a/hgext/chgcache.py b/hgext/chgcache.py
new file mode 100644
--- /dev/null
+++ b/hgext/chgcache.py
@@ -0,0 +1,11 @@
+# chgcache.py - add repo-level preloading functionality to chg
+#
+# Copyright 2017 Facebook, Inc.
+#
+# This software may be used and distributed according to the terms of the
+# GNU General Public License version 2 or any later version.
+"""repo-level caching for chg (EXPERIMENTAL)
+
+With this extension installed, Mercurial running with chg will be able to cache
+repo objects to further reduce start-up time.
+"""
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 4 of 4 RFC] chgcache: add the background preloading thread

2017-02-08 Thread Jun Wu
# HG changeset patch
# User Jun Wu 
# Date 1486604289 28800
#  Wed Feb 08 17:38:09 2017 -0800
# Node ID 79adf3722f1b0f602e9461f13fa940a25dbfce56
# Parent  88c498ad9318df115d8408412a38edbac7d92a6a
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 79adf3722f1b
chgcache: add the background preloading thread

This patch adds the background preloading thread that runs in the chg master
process. It reads and drains the IPC channel, but does not actually preload
anything yet.

diff --git a/hgext/chgcache.py b/hgext/chgcache.py
--- a/hgext/chgcache.py
+++ b/hgext/chgcache.py
@@ -14,4 +14,5 @@ from __future__ import absolute_import
 import socket
 import sys
+import threading
 import time
 
@@ -77,4 +78,5 @@ class socketipc(object):
 
 _ipc = socketipc()
+_repocaches = {} # {repopath: (mtime, cache)}
 
 # -- only used by the forked worker process ---
@@ -94,4 +96,19 @@ def _runcommand(orig, self):
 return result
 
+# -- only used by the master process --
+
+def _backgroundpreloader(interval=0.5):
+while True:
+try:
+atime, path = _ipc.recv().split(' ', 1)
+except Exception: # format error
+pass
+else:
+if path in _repocaches and _repocaches[path][0] >= atime:
+# the repo cache is up-to-date
+continue
+now = time.time()
+_repocaches[path] = (now, None)
+
 # -
 
@@ -109,2 +126,8 @@ def extsetup(ui):
 caps = chgserver.chgcmdserver.capabilities
 caps['runcommand'] = extensions.bind(_runcommand, caps['runcommand'])
+
+# start the background preloader
+t = threading.Thread(target=_backgroundpreloader,
+ name='chgcache-backgroundpreloader')
+t.daemon = True
+t.start()
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 3 of 4 RFC] chgcache: report repo paths from worker to master

2017-02-08 Thread Jun Wu
# HG changeset patch
# User Jun Wu 
# Date 1486603691 28800
#  Wed Feb 08 17:28:11 2017 -0800
# Node ID 88c498ad9318df115d8408412a38edbac7d92a6a
# Parent  8410c4a6703bed4b459cf8d62bd32fdcb1e7
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 88c498ad9318
chgcache: report repo paths from worker to master

This patch makes chg workers report repo paths accessed to the chg master,
via the IPC utility added by the last patch.

In additional of repo paths, we also send out timestamps, so the master
server could avoid preloading a same repo if it was accessed frequently and
was queued many times in the ipc channel.

diff --git a/hgext/chgcache.py b/hgext/chgcache.py
--- a/hgext/chgcache.py
+++ b/hgext/chgcache.py
@@ -13,4 +13,13 @@ from __future__ import absolute_import
 
 import socket
+import sys
+import time
+
+from mercurial import (
+chgserver,
+dispatch,
+extensions,
+localrepo,
+)
 
 class socketipc(object):
@@ -64,2 +73,38 @@ class socketipc(object):
 except socket.error:
 pass
+
+# -- shared by both the forked worker, and the master -
+
+_ipc = socketipc()
+
+# -- only used by the forked worker process ---
+
+_repopaths = set() # repo paths to send to the master after runcommand
+
+def _repoinit(orig, self, baseui, path=None, create=False):
+if path and not create:
+_repopaths.add(path)
+orig(self, baseui, path, create)
+
+def _runcommand(orig, self):
+result = orig(self)
+now = time.time()
+for path in _repopaths:
+_ipc.send('%s %s' % (now, path))
+return result
+
+# -
+
+def extsetup(ui):
+# this extension is a no-op if chg is not used
+# TODO(quark): change "extsetup" to "chgsetup", and discard the hacker
+# check, after the related chg change is done.
+if 'chgunix' not in dispatch._earlygetopt(['--cmdserver'], sys.argv[:]):
+return
+
+# collect paths of repos being accessed
+extensions.wrapfunction(localrepo.localrepository, '__init__', _repoinit)
+
+# let chg worker report repo paths to chg master, after a command completes
+caps = chgserver.chgcmdserver.capabilities
+caps['runcommand'] = extensions.bind(_runcommand, caps['runcommand'])
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 2 of 2 V2] commandserver: handle backlog before exiting

2017-02-08 Thread Jun Wu
# HG changeset patch
# User Jun Wu 
# Date 1486593930 28800
#  Wed Feb 08 14:45:30 2017 -0800
# Node ID cb56fce57eceef2cf4cd9893d387b9fe2b3cecd6
# Parent  5fc577761fb78168fcbd7ec93d911a1b7b4989c9
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r cb56fce57ece
commandserver: handle backlog before exiting

Previously, when a chg server is exiting, it does not handle connected
clients so clients may get ECONNRESET and crash:

  1. client connect() # success
  2. server shouldexit = True and exit
  3. client recv() # ECONNRESET

d7875bfbfccb makes this race condition easier to reproduce if a lot of short
chg commands are started in parallel.

This patch fixes the above issue by unlinking the socket path to stop
queuing new connections and processing all pending connections before exit.

diff --git a/mercurial/commandserver.py b/mercurial/commandserver.py
--- a/mercurial/commandserver.py
+++ b/mercurial/commandserver.py
@@ -478,9 +478,21 @@ class unixforkingservice(object):
 
 def _mainloop(self):
+exiting = False
 h = self._servicehandler
-while not h.shouldexit():
+while True:
+if not exiting and h.shouldexit():
+# clients can no longer connect() to the domain socket, so
+# we stop queuing new requests.
+# for requests that are queued (connect()-ed, but haven't been
+# accept()-ed), handle them before exit. otherwise, clients
+# waiting for recv() will receive ECONNRESET.
+self._servicehandler.unlinksocket(self.address)
+exiting = True
 try:
 ready = select.select([self._sock], [], [], h.pollinterval)[0]
 if not ready:
+# only exit if we completed all queued requests
+if exiting:
+break
 continue
 conn, _addr = self._sock.accept()
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 1 of 2 V2] commandserver: prevent unlink socket twice

2017-02-08 Thread Jun Wu
# HG changeset patch
# User Jun Wu 
# Date 1486593458 28800
#  Wed Feb 08 14:37:38 2017 -0800
# Node ID 5fc577761fb78168fcbd7ec93d911a1b7b4989c9
# Parent  a68510b69f413545722c086eaeb840dd5e8305b4
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 5fc577761fb7
commandserver: prevent unlink socket twice

This patch changes unixforkingservice so it only calls
`self._servicehandler.unlinksocket(self.address)` at most once.

This is needed by the next patch.

diff --git a/mercurial/commandserver.py b/mercurial/commandserver.py
--- a/mercurial/commandserver.py
+++ b/mercurial/commandserver.py
@@ -448,4 +448,5 @@ class unixforkingservice(object):
 self._oldsigchldhandler = None
 self._workerpids = set()  # updated by signal handler; do not iterate
+self._socketunlinked = None
 
 def init(self):
@@ -456,9 +457,15 @@ class unixforkingservice(object):
 self._oldsigchldhandler = o
 self._servicehandler.printbanner(self.address)
+self._socketunlinked = False
+
+def _unlinksocket(self):
+if not self._socketunlinked:
+self._servicehandler.unlinksocket(self.address)
+self._socketunlinked = True
 
 def _cleanup(self):
 signal.signal(signal.SIGCHLD, self._oldsigchldhandler)
 self._sock.close()
-self._servicehandler.unlinksocket(self.address)
+self._unlinksocket()
 # don't kill child processes as they have active clients, just wait
 self._reapworkers(0)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH 1 of 3 pager-in-core-prep] pager: add a test of --pager=no functionality

2017-02-08 Thread Bryan O'Sullivan
On Tue, Feb 7, 2017 at 2:23 PM, Augie Fackler  wrote:

> These three patches are the prep work for a long series that moves
> pager to core and makes it on by default.
>

These 3 look good. Thanks!
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] pager: exit cleanly on SIGPIPE (BC)

2017-02-08 Thread David Soria Parra
On Wed, Feb 08, 2017 at 07:47:39AM -0800, Simon Farnsworth wrote:
> # HG changeset patch
> # User Simon Farnsworth 
> # Date 1486568650 28800
> #  Wed Feb 08 07:44:10 2017 -0800
> # Node ID d50cda2a403786836d1f0d5c99401599dc4f43ec
> # Parent  1f51b4658f21bbb797e922d155c1046eddccf91d
> pager: exit cleanly on SIGPIPE (BC)
> 

LGTM
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: Does chg need to be its own program?

2017-02-08 Thread Jun Wu
I think you are talking about the "entry point", which is different from
"chg".

At Facebook, "hg" is a wrapper that reads a tiny config file, and calls
either "chg" or "hg.real", where "hg.real" is the "hg" script elsewhere.

So it makes sense to have a very lightweight binary that basically execs chg
or hg, or be a complicated, customized Python interpreter.

Note that I think it's architecturally cleaner to still have a separated
"chg" binary, free from any Python stuff. But I'm not insisting on that
setup. If we decide to merge chg and the Python interpreter into a single
process, to make deployment easier eventually, it'll still be nice to have
chg and Python.h related stuff separated at source code level.

About "chg by default", I think test automation may dislike chg - orphaned
background daemon processes are generally not expected in a test environment
and the POSIX does not provide good APIs to detect those processes. So I'm
conservative on this. It may make sense to turn on chg on TTYs, like what we
did for --color=auto.

Excerpts from Gregory Szorc's message of 2017-02-08 10:35:32 -0800:
> Currently, chg is its own standalone C program. When invoked, it spawns a
> Python/hg process (if necessary) then talks to it.
> 
> A major disadvantage of this approach is that users need to install chg
> (currently separately) and alias it to `hg` in their shell. This means
> adoption is difficult. chg should "just work."
> 
> On Windows today, we compile and install a C wrapper program providing
> hg.exe (see exewrapper.c). This program loads the Python shared library and
> calls Py_Main() to start an embedded Python interpreter running hg's main
> routine.
> 
> Could this approach be leveraged for chg?
> 
> Making `hg` itself a C program would make chg "just work." I think it also
> opens up some interesting performance optimizations, such as running
> multiple Python interpreters in a single process (IIRC the GIL is per
> interpreter not per-process) and bypassing dispatch overhead by leveraging
> Python C APIs to eval a code object directly. Of course, it also lends
> itself to interesting caching possibilities, like what Jun is proposing in
> another thread. This could be as simple as starting an empty Python
> interpreter and fork()ing at command time to avoid Python interpreter
> startup overhead.
> 
> It's worth noting that `hg` as a C program wouldn't necessarily need to
> adopt chg's daemon model. There could be some wins from having full control
> over the Python interpreter.
> 
> Of course `hg` as a C program would be optional and opt in until it
> stabilizes. setup.py already conditionally installs `hg.exe`. But once we
> deem chg stable enough, we can enable it and users will automatically see
> the benefits when they upgrade.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: Does chg need to be its own program?

2017-02-08 Thread Sean Farley
Gregory Szorc  writes:

> Currently, chg is its own standalone C program. When invoked, it spawns a
> Python/hg process (if necessary) then talks to it.
>
> A major disadvantage of this approach is that users need to install chg
> (currently separately) and alias it to `hg` in their shell. This means
> adoption is difficult. chg should "just work."

For the mac package, I believe Augie is going to bundle it. For
macports, I've been including chg for over a year.

> On Windows today, we compile and install a C wrapper program providing
> hg.exe (see exewrapper.c). This program loads the Python shared library and
> calls Py_Main() to start an embedded Python interpreter running hg's main
> routine.
>
> Could this approach be leveraged for chg?
>
> Making `hg` itself a C program would make chg "just work." I think it also
> opens up some interesting performance optimizations, such as running
> multiple Python interpreters in a single process (IIRC the GIL is per
> interpreter not per-process) and bypassing dispatch overhead by leveraging
> Python C APIs to eval a code object directly. Of course, it also lends
> itself to interesting caching possibilities, like what Jun is proposing in
> another thread. This could be as simple as starting an empty Python
> interpreter and fork()ing at command time to avoid Python interpreter
> startup overhead.
>
> It's worth noting that `hg` as a C program wouldn't necessarily need to
> adopt chg's daemon model. There could be some wins from having full control
> over the Python interpreter.
>
> Of course `hg` as a C program would be optional and opt in until it
> stabilizes. setup.py already conditionally installs `hg.exe`. But once we
> deem chg stable enough, we can enable it and users will automatically see
> the benefits when they upgrade.

I dunno. This sounds too complicated for me to think about right, and I
have bigger fish to fry. I'll let Yuya and Jun share their thoughts.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Does chg need to be its own program?

2017-02-08 Thread Gregory Szorc
Currently, chg is its own standalone C program. When invoked, it spawns a
Python/hg process (if necessary) then talks to it.

A major disadvantage of this approach is that users need to install chg
(currently separately) and alias it to `hg` in their shell. This means
adoption is difficult. chg should "just work."

On Windows today, we compile and install a C wrapper program providing
hg.exe (see exewrapper.c). This program loads the Python shared library and
calls Py_Main() to start an embedded Python interpreter running hg's main
routine.

Could this approach be leveraged for chg?

Making `hg` itself a C program would make chg "just work." I think it also
opens up some interesting performance optimizations, such as running
multiple Python interpreters in a single process (IIRC the GIL is per
interpreter not per-process) and bypassing dispatch overhead by leveraging
Python C APIs to eval a code object directly. Of course, it also lends
itself to interesting caching possibilities, like what Jun is proposing in
another thread. This could be as simple as starting an empty Python
interpreter and fork()ing at command time to avoid Python interpreter
startup overhead.

It's worth noting that `hg` as a C program wouldn't necessarily need to
adopt chg's daemon model. There could be some wins from having full control
over the Python interpreter.

Of course `hg` as a C program would be optional and opt in until it
stabilizes. setup.py already conditionally installs `hg.exe`. But once we
deem chg stable enough, we can enable it and users will automatically see
the benefits when they upgrade.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 2 of 2] py3: fix the way we produce bytes list in store.py

2017-02-08 Thread Pulkit Goyal
# HG changeset patch
# User Pulkit Goyal <7895pul...@gmail.com>
# Date 1486490137 -19800
#  Tue Feb 07 23:25:37 2017 +0530
# Node ID 47e72d467dd8da66092ca6b6a91235d8432e2dc1
# Parent  61c589c75ebbce625d7056297e122863b68acce9
py3: fix the way we produce bytes list in store.py

bytes(range(127)) does not produce a list whereas we need a list. This patch
fixes that.

diff -r 61c589c75ebb -r 47e72d467dd8 mercurial/store.py
--- a/mercurial/store.pyTue Feb 07 22:47:24 2017 +0530
+++ b/mercurial/store.pyTue Feb 07 23:25:37 2017 +0530
@@ -101,7 +101,7 @@
 e = '_'
 if pycompat.ispy3:
 xchr = lambda x: bytes([x])
-asciistr = bytes(xrange(127))
+asciistr = [bytes(a) for a in range(127)]
 else:
 xchr = chr
 asciistr = map(chr, xrange(127))
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 1 of 2] py3: convert os.__file__ to bytes

2017-02-08 Thread Pulkit Goyal
# HG changeset patch
# User Pulkit Goyal <7895pul...@gmail.com>
# Date 1486487844 -19800
#  Tue Feb 07 22:47:24 2017 +0530
# Node ID 61c589c75ebbce625d7056297e122863b68acce9
# Parent  a68510b69f413545722c086eaeb840dd5e8305b4
py3: convert os.__file__ to bytes

os.__file__ returns unicode path on Python 3. We need to have bytespath. This
patch uses pycompat.fsencode() to encode unicode path to bytes path.

diff -r a68510b69f41 -r 61c589c75ebb mercurial/commands.py
--- a/mercurial/commands.py Mon Feb 06 17:01:06 2017 -0800
+++ b/mercurial/commands.py Tue Feb 07 22:47:24 2017 +0530
@@ -1903,7 +1903,7 @@
 fm.write('pythonver', _("checking Python version (%s)\n"),
  ("%d.%d.%d" % sys.version_info[:3]))
 fm.write('pythonlib', _("checking Python lib (%s)...\n"),
- os.path.dirname(os.__file__))
+ os.path.dirname(pycompat.fsencode(os.__file__)))
 
 security = set(sslutil.supportedprotocols)
 if sslutil.hassni:
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH STABLE] doc: update year in copyright lines

2017-02-08 Thread FUJIWARA Katsunori
# HG changeset patch
# User FUJIWARA Katsunori 
# Date 1486572068 -32400
#  Thu Feb 09 01:41:08 2017 +0900
# Branch stable
# Node ID 05b83627f1922f34680664080b22bd2b8baac91a
# Parent  af3b5aa61fc05a124697809bf472a5592f38489c
doc: update year in copyright lines

This patch also makes some expected output lines in tests glob-ed for
persistence of them.

I already have patches to avoid this kind of overlooking at the end of
this or later years. But they aren't posted as a part of this series,
because they aren't needed immediately. They should be landed on
"default" branch.

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -6576,7 +6576,7 @@ def version_(ui, **opts):
  util.version())
 license = _(
 "(see https://mercurial-scm.org for more information)\n"
-"\nCopyright (C) 2005-2016 Matt Mackall and others\n"
+"\nCopyright (C) 2005-2017 Matt Mackall and others\n"
 "This is free software; see the source for copying conditions. "
 "There is NO\nwarranty; "
 "not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n"
diff --git a/mercurial/help/hg-ssh.8.txt b/mercurial/help/hg-ssh.8.txt
--- a/mercurial/help/hg-ssh.8.txt
+++ b/mercurial/help/hg-ssh.8.txt
@@ -64,7 +64,7 @@ Mailing list: https://www.mercurial-scm.
 
 Copying
 """
-Copyright (C) 2005-2016 Matt Mackall.
+Copyright (C) 2005-2017 Matt Mackall.
 Free use of this software is granted under the terms of the GNU General
 Public License version 2 or any later version.
 
diff --git a/mercurial/help/hg.1.txt b/mercurial/help/hg.1.txt
--- a/mercurial/help/hg.1.txt
+++ b/mercurial/help/hg.1.txt
@@ -112,7 +112,7 @@ Mailing list: https://www.mercurial-scm.
 
 Copying
 """
-Copyright (C) 2005-2016 Matt Mackall.
+Copyright (C) 2005-2017 Matt Mackall.
 Free use of this software is granted under the terms of the GNU General
 Public License version 2 or any later version.
 
diff --git a/mercurial/help/hgignore.5.txt b/mercurial/help/hgignore.5.txt
--- a/mercurial/help/hgignore.5.txt
+++ b/mercurial/help/hgignore.5.txt
@@ -26,7 +26,7 @@ See Also
 Copying
 ===
 This manual page is copyright 2006 Vadim Gelfer.
-Mercurial is copyright 2005-2016 Matt Mackall.
+Mercurial is copyright 2005-2017 Matt Mackall.
 Free use of this software is granted under the terms of the GNU General
 Public License version 2 or any later version.
 
diff --git a/mercurial/help/hgrc.5.txt b/mercurial/help/hgrc.5.txt
--- a/mercurial/help/hgrc.5.txt
+++ b/mercurial/help/hgrc.5.txt
@@ -34,7 +34,7 @@ See Also
 Copying
 ===
 This manual page is copyright 2005 Bryan O'Sullivan.
-Mercurial is copyright 2005-2016 Matt Mackall.
+Mercurial is copyright 2005-2017 Matt Mackall.
 Free use of this software is granted under the terms of the GNU General
 Public License version 2 or any later version.
 
diff --git a/tests/test-help.t b/tests/test-help.t
--- a/tests/test-help.t
+++ b/tests/test-help.t
@@ -445,7 +445,7 @@ Test help option with version option
   Mercurial Distributed SCM (version *) (glob)
   (see https://mercurial-scm.org for more information)
   
-  Copyright (C) 2005-2016 Matt Mackall and others
+  Copyright (C) 2005-* Matt Mackall and others (glob)
   This is free software; see the source for copying conditions. There is NO
   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
diff --git a/tests/test-hgrc.t b/tests/test-hgrc.t
--- a/tests/test-hgrc.t
+++ b/tests/test-hgrc.t
@@ -71,7 +71,7 @@ issue1829: wrong indentation
   Mercurial Distributed SCM (version *) (glob)
   (see https://mercurial-scm.org for more information)
   
-  Copyright (C) 2005-2016 Matt Mackall and others
+  Copyright (C) 2005-* Matt Mackall and others (glob)
   This is free software; see the source for copying conditions. There is NO
   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
   $ unset FAKEPATH
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH v2] hg: allow usage of XDG_CONFIG_HOME and $HOME/.config/hgrc

2017-02-08 Thread Raffaele Salmaso
On Wed, Feb 8, 2017 at 5:01 PM, Augie Fackler  wrote:

> > hg: allow usage of XDG_CONFIG_HOME and $HOME/.config/hgrcThat said, pip
> looks at $XDG_CONFIG_HOME/pip, so I suspect (the spec is unclear) that we
> should be storing things in $XDG_CONFIG_HOME/hg - that's also consistent
> with what git does (search for XDG_CONFIG on https://git-scm.com/docs/git-
> config)
>
Yes, I use this configuration (export
HGRCPATH=$HOME/.local/mercurial/hgrc), and put in $HOME/.local/mercurial my
personal style and some custom extensions (evolve...).


-- 
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH v3] hg: allow usage of XDG_CONFIG_HOME and $HOME/.config/hg/hgrc

2017-02-08 Thread David Demelier
# HG changeset patch
# User David Demelier 
# Date 1486485215 -3600
#  Tue Feb 07 17:33:35 2017 +0100
# Node ID 5ecf752f0a79482fe2cecfa73c5a733dab29fb88
# Parent  1f51b4658f21bbb797e922d155c1046eddccf91d
hg: allow usage of XDG_CONFIG_HOME and $HOME/.config/hg/hgrc

Modern applications must use the following paths to store configuration files:

  - $XDG_CONFIG_HOME/hg/hgrc
  - $HOME/.config/hg/hgrc (if XDG_CONFIG_HOME is not set)

For convenience, these paths are now evaluated first and the old $HOME/.hgrc is
used as a fallback.

See https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

diff -r 1f51b4658f21 -r 5ecf752f0a79 mercurial/help/config.txt
--- a/mercurial/help/config.txt Thu Feb 02 14:19:48 2017 +0100
+++ b/mercurial/help/config.txt Tue Feb 07 17:33:35 2017 +0100
@@ -55,6 +55,8 @@
   On Unix, the following files are consulted:
 
   - ``/.hg/hgrc`` (per-repository)
+  - ``$XDG_CONFIG_HOME/hg/hgrc`` (per-user)
+  - ``$HOME/.config/hg/hgrc`` (per-user)
   - ``$HOME/.hgrc`` (per-user)
   - ``/etc/mercurial/hgrc`` (per-installation)
   - ``/etc/mercurial/hgrc.d/*.rc`` (per-installation)
diff -r 1f51b4658f21 -r 5ecf752f0a79 mercurial/scmposix.py
--- a/mercurial/scmposix.py Thu Feb 02 14:19:48 2017 +0100
+++ b/mercurial/scmposix.py Tue Feb 07 17:33:35 2017 +0100
@@ -40,8 +40,16 @@
 def userrcpath():
 if pycompat.sysplatform == 'plan9':
 return [encoding.environ['home'] + '/lib/hgrc']
+elif pycompat.sysplatform == 'darwin':
+return [os.path.expanduser('~/.hgrc')]
 else:
-return [os.path.expanduser('~/.hgrc')]
+home = encoding.environ.get('XDG_CONFIG_HOME',
+os.path.expanduser('~/.config'))
+path = os.path.join(home, 'hg/hgrc')
+if os.path.isfile(path):
+return [path]
+else:
+return [os.path.expanduser('~/.hgrc')]
 
 def termsize(ui):
 try:
diff -r 1f51b4658f21 -r 5ecf752f0a79 tests/test-xdg.t
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/tests/test-xdg.t  Tue Feb 07 17:33:35 2017 +0100
@@ -0,0 +1,11 @@
+#if no-windows no-osx
+
+  $ mkdir -p xdgconf/hg
+  $ echo '[ui]' > xdgconf/hg/hgrc
+  $ echo 'username = foobar' >> xdgconf/hg/hgrc
+  $ XDG_CONFIG_HOME=xdgconf; export XDG_CONFIG_HOME
+  $ unset HGRCPATH
+  $ hg config ui.username
+  foobar
+
+#endif
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH] zeroconf: fail nicely on IPv6 only system

2017-02-08 Thread Simon Farnsworth
# HG changeset patch
# User Simon Farnsworth 
# Date 1486570121 28800
#  Wed Feb 08 08:08:41 2017 -0800
# Node ID a847eb00fcfeffce458e11b80ad38d4d4e7a700f
# Parent  d50cda2a403786836d1f0d5c99401599dc4f43ec
zeroconf: fail nicely on IPv6 only system

zeroconf only knows how to deal with IPv4; I develop on a system where the only
IPv4 address is 127.0.0.1.

Teach zeroconf to ignore IPv6 addresses when looking for plausible IPv4
connectivity.

diff --git a/hgext/zeroconf/__init__.py b/hgext/zeroconf/__init__.py
--- a/hgext/zeroconf/__init__.py
+++ b/hgext/zeroconf/__init__.py
@@ -64,7 +64,9 @@
 # Generic method, sometimes gives useless results
 try:
 dumbip = socket.gethostbyaddr(socket.gethostname())[2][0]
-if not dumbip.startswith('127.') and ':' not in dumbip:
+if ':' in dumbip:
+dumbip = '127.0.0.1'
+if not dumbip.startswith('127.'):
 return dumbip
 except (socket.gaierror, socket.herror):
 dumbip = '127.0.0.1'
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] pager: exit cleanly on SIGPIPE (BC)

2017-02-08 Thread Simon Farnsworth

This replaces "dispatch: treat SIGPIPE as a termination signal (BC)".

I'm now debugging test-paths.t, so that I can stop being acclimatised to 
the red failure prompt after running tests, to improve my chances of 
noticing this sort of issue.


Simon

On 08/02/2017 15:47, Simon Farnsworth wrote:

# HG changeset patch
# User Simon Farnsworth 
# Date 1486568650 28800
#  Wed Feb 08 07:44:10 2017 -0800
# Node ID d50cda2a403786836d1f0d5c99401599dc4f43ec
# Parent  1f51b4658f21bbb797e922d155c1046eddccf91d
pager: exit cleanly on SIGPIPE (BC)

Changeset aaa751585325 removes SIGPIPE handling completely. This is wrong,
as it means that Mercurial does not exit when the pager does. Instead, raise
SignalInterrupt when SIGPIPE happens with a pager attached, to trigger the
normal exit path.

This will cause "killed!" to be printed to stderr (hence the BC warning),
but in the normal pager use case (where the pager gets both stderr and
stdout), this messsage is lost as we only get SIGPIPE when the pager quits.

diff --git a/hgext/pager.py b/hgext/pager.py
--- a/hgext/pager.py
+++ b/hgext/pager.py
@@ -72,6 +72,7 @@
 commands,
 dispatch,
 encoding,
+error,
 extensions,
 util,
 )
@@ -114,6 +115,9 @@
 os.dup2(stderrfd, util.stderr.fileno())
 pager.wait()

+def catchterm(*args):
+raise error.SignalInterrupt
+
 def uisetup(ui):
 class pagerui(ui.__class__):
 def _runpager(self, pagercmd):
@@ -153,6 +157,8 @@
 if usepager:
 ui.setconfig('ui', 'formatted', ui.formatted(), 'pager')
 ui.setconfig('ui', 'interactive', False, 'pager')
+if util.safehasattr(signal, "SIGPIPE"):
+signal.signal(signal.SIGPIPE, catchterm)
 ui._runpager(p)
 return orig(ui, options, cmd, cmdfunc)

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mercurial-2Dscm.org_mailman_listinfo_mercurial-2Ddevel=DwIGaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=JGdkzd8E23MJxg59Iu-jc-4lKtVDPSGtiCxGk7Tvyfk=26T_I6At53KfO_UPKKWvM8tgFUbZStBE44m6jbEfsrk=



--
Simon Farnsworth
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH] pager: exit cleanly on SIGPIPE (BC)

2017-02-08 Thread Simon Farnsworth
# HG changeset patch
# User Simon Farnsworth 
# Date 1486568650 28800
#  Wed Feb 08 07:44:10 2017 -0800
# Node ID d50cda2a403786836d1f0d5c99401599dc4f43ec
# Parent  1f51b4658f21bbb797e922d155c1046eddccf91d
pager: exit cleanly on SIGPIPE (BC)

Changeset aaa751585325 removes SIGPIPE handling completely. This is wrong,
as it means that Mercurial does not exit when the pager does. Instead, raise
SignalInterrupt when SIGPIPE happens with a pager attached, to trigger the
normal exit path.

This will cause "killed!" to be printed to stderr (hence the BC warning),
but in the normal pager use case (where the pager gets both stderr and
stdout), this messsage is lost as we only get SIGPIPE when the pager quits.

diff --git a/hgext/pager.py b/hgext/pager.py
--- a/hgext/pager.py
+++ b/hgext/pager.py
@@ -72,6 +72,7 @@
 commands,
 dispatch,
 encoding,
+error,
 extensions,
 util,
 )
@@ -114,6 +115,9 @@
 os.dup2(stderrfd, util.stderr.fileno())
 pager.wait()
 
+def catchterm(*args):
+raise error.SignalInterrupt
+
 def uisetup(ui):
 class pagerui(ui.__class__):
 def _runpager(self, pagercmd):
@@ -153,6 +157,8 @@
 if usepager:
 ui.setconfig('ui', 'formatted', ui.formatted(), 'pager')
 ui.setconfig('ui', 'interactive', False, 'pager')
+if util.safehasattr(signal, "SIGPIPE"):
+signal.signal(signal.SIGPIPE, catchterm)
 ui._runpager(p)
 return orig(ui, options, cmd, cmdfunc)
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] dispatch: treat SIGPIPE as a termination signal (BC)

2017-02-08 Thread Simon Farnsworth
Please scrub this - it breaks `hg serve`. I'll send a v2 shortly, that 
moves the SIGPIPE handling into pager and thus has no BC implications.


On 07/02/2017 20:08, Simon Farnsworth wrote:

# HG changeset patch
# User Simon Farnsworth 
# Date 1486498104 28800
#  Tue Feb 07 12:08:24 2017 -0800
# Node ID e1150763706818fffa62c81a72a88574d20caea1
# Parent  1f51b4658f21bbb797e922d155c1046eddccf91d
dispatch: treat SIGPIPE as a termination signal (BC)

pager previously set SIGPIPE to immediately exit the process, ignoring any
Python @atexit handlers, exception handling etc - just instant termination.

Simply removing this as per changeset aaa751585325 meant that when you
aborted a long running pager command, Mercurial would not quit; instead, we
should add SIGPIPE to the list of termination signals in dispatch.py.

This is a slight BC break, as previously, a process that was piping data
into or out of Mercurial would not kill Mercurial if it died before closing
its end of the pipe, whereas it will now cause Mercurial to exit.

diff --git a/mercurial/dispatch.py b/mercurial/dispatch.py
--- a/mercurial/dispatch.py
+++ b/mercurial/dispatch.py
@@ -147,7 +147,7 @@

 ui = req.ui
 try:
-for name in 'SIGBREAK', 'SIGHUP', 'SIGTERM':
+for name in 'SIGBREAK', 'SIGHUP', 'SIGTERM', 'SIGPIPE':
 num = getattr(signal, name, None)
 if num:
 signal.signal(num, catchterm)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mercurial-2Dscm.org_mailman_listinfo_mercurial-2Ddevel=DwIGaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=I0DTIf8TaBNbZo11b6eM-M9WIaAj0Va9TR_a9fvAsvk=629TWBre1WtsIXDvJQh3UKr9baaDbd6LlVXnmQeyP5E=



--
Simon Farnsworth
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH v2] hg: allow usage of XDG_CONFIG_HOME and $HOME/.config/hgrc

2017-02-08 Thread David Demelier
# HG changeset patch
# User David Demelier 
# Date 1486485215 -3600
#  Tue Feb 07 17:33:35 2017 +0100
# Node ID 880021eb7ec0be00c76739cb647e0f5712420c81
# Parent  1f51b4658f21bbb797e922d155c1046eddccf91d
hg: allow usage of XDG_CONFIG_HOME and $HOME/.config/hgrc

Modern applications must use the following paths to store configuration files:

  - $XDG_CONFIG_HOME/hgrc
  - $HOME/.config/hgrc (if XDG_CONFIG_HOME is not set)

For convenience, these paths are now evaluated first and the old $HOME/.hgrc is
used as a fallback.

See https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

diff -r 1f51b4658f21 -r 880021eb7ec0 mercurial/help/config.txt
--- a/mercurial/help/config.txt Thu Feb 02 14:19:48 2017 +0100
+++ b/mercurial/help/config.txt Tue Feb 07 17:33:35 2017 +0100
@@ -55,6 +55,8 @@
   On Unix, the following files are consulted:
 
   - ``/.hg/hgrc`` (per-repository)
+  - ``$XDG_CONFIG_HOME/hgrc`` (per-user)
+  - ``$HOME/.config/hgrc`` (per-user)
   - ``$HOME/.hgrc`` (per-user)
   - ``/etc/mercurial/hgrc`` (per-installation)
   - ``/etc/mercurial/hgrc.d/*.rc`` (per-installation)
diff -r 1f51b4658f21 -r 880021eb7ec0 mercurial/scmposix.py
--- a/mercurial/scmposix.py Thu Feb 02 14:19:48 2017 +0100
+++ b/mercurial/scmposix.py Tue Feb 07 17:33:35 2017 +0100
@@ -41,7 +41,15 @@
 if pycompat.sysplatform == 'plan9':
 return [encoding.environ['home'] + '/lib/hgrc']
 else:
-return [os.path.expanduser('~/.hgrc')]
+xdg = encoding.environ.get("XDG_CONFIG_HOME")
+if xdg is not None:
+return [os.path.join(xdg, "hgrc")]
+else:
+cfg = os.path.expanduser("~/.config/hgrc")
+if os.path.isfile(cfg):
+return [cfg]
+else:
+return [os.path.expanduser('~/.hgrc')]
 
 def termsize(ui):
 try:
diff -r 1f51b4658f21 -r 880021eb7ec0 tests/test-xdg.t
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/tests/test-xdg.t  Tue Feb 07 17:33:35 2017 +0100
@@ -0,0 +1,11 @@
+#if no-windows
+
+  $ mkdir xdgconf
+  $ echo '[ui]' > xdgconf/hgrc
+  $ echo 'username = foobar' >> xdgconf/hgrc
+  $ XDG_CONFIG_HOME=xdgconf; export XDG_CONFIG_HOME
+  $ unset HGRCPATH
+  $ hg config ui.username
+  foobar
+
+#endif
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] hg: allow usage of XDG_CONFIG_HOME and $HOME/.config/hgrc

2017-02-08 Thread David Demelier

Le 07/02/2017 à 17:52, David Demelier a écrit :

# HG changeset patch
# User David Demelier 
# Date 1486485215 -3600
#  Tue Feb 07 17:33:35 2017 +0100
# Node ID 699fb7d08bdf2329fdb64df56e72d6c07cd91285
# Parent  1f51b4658f21bbb797e922d155c1046eddccf91d
hg: allow usage of XDG_CONFIG_HOME and $HOME/.config/hgrc

Modern applications must use the following paths to store configuration files:

  - $XDG_CONFIG_HOME/hgrc
  - $HOME/.config/hgrc (if XDG_CONFIG_HOME is not set)

For convenience, these paths are now evaluated first and the old $HOME/.hgrc is
used as a fallback.

See https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

diff -r 1f51b4658f21 -r 699fb7d08bdf mercurial/help/config.txt
--- a/mercurial/help/config.txt Thu Feb 02 14:19:48 2017 +0100
+++ b/mercurial/help/config.txt Tue Feb 07 17:33:35 2017 +0100
@@ -55,6 +55,8 @@
   On Unix, the following files are consulted:

   - ``/.hg/hgrc`` (per-repository)
+  - ``$XDG_CONFIG_HOME/hgrc`` (per-user)
+  - ``$HOME/.config/hgrc`` (per-user)
   - ``$HOME/.hgrc`` (per-user)
   - ``/etc/mercurial/hgrc`` (per-installation)
   - ``/etc/mercurial/hgrc.d/*.rc`` (per-installation)
diff -r 1f51b4658f21 -r 699fb7d08bdf mercurial/scmposix.py
--- a/mercurial/scmposix.py Thu Feb 02 14:19:48 2017 +0100
+++ b/mercurial/scmposix.py Tue Feb 07 17:33:35 2017 +0100
@@ -41,7 +41,15 @@
 if pycompat.sysplatform == 'plan9':
 return [encoding.environ['home'] + '/lib/hgrc']
 else:
-return [os.path.expanduser('~/.hgrc')]
+xdg = encoding.environ.get("XDG_CONFIG_HOME")
+if xdg is not None:
+return [os.path.join(xdg, "hgrc")]
+else:
+cfg = os.path.expanduser("~/.config/hgrc")
+if os.path.isfile(cfg):
+return [cfg]
+else:
+return [os.path.expanduser('~/.hgrc')]

 def termsize(ui):
 try:



I wanted to add the following tests but could not get it to work:

$ cat tests/test-xdg.t
  $ mkdir xdgconf
  $ echo '[ui]' > xdgconf/hgrc
  $ echo 'username = foobar' >> xdgconf/hgrc
  $ XDG_CONFIG_HOME=xdgconf; export XDG_CONFIG_HOME
  $ hg config ui.username
  foobar

I've tried the following:

make PYTHON=python2.7 local
cd tests
python2.7 run-tests.py --local test-xdg.t

--- /home/markand/hg/tests/test-xdg.t
+++ /home/markand/hg/tests/test-xdg.t.err
@@ -3,4 +3,4 @@
   $ echo 'username = foobar' >> xdgconf/hgrc
   $ XDG_CONFIG_HOME=xdgconf; export XDG_CONFIG_HOME
   $ hg config ui.username
-  foobar
+  [1]

ERROR: test-xdg.t output changed
!
Failed test-xdg.t: output changed
# Ran 1 tests, 0 skipped, 0 warned, 1 failed.
python hash seed: 3897982799

But once installed; it works.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH] hg: allow usage of XDG_CONFIG_HOME and $HOME/.config/hgrc

2017-02-08 Thread David Demelier
# HG changeset patch
# User David Demelier 
# Date 1486485215 -3600
#  Tue Feb 07 17:33:35 2017 +0100
# Node ID 699fb7d08bdf2329fdb64df56e72d6c07cd91285
# Parent  1f51b4658f21bbb797e922d155c1046eddccf91d
hg: allow usage of XDG_CONFIG_HOME and $HOME/.config/hgrc

Modern applications must use the following paths to store configuration files:

  - $XDG_CONFIG_HOME/hgrc
  - $HOME/.config/hgrc (if XDG_CONFIG_HOME is not set)

For convenience, these paths are now evaluated first and the old $HOME/.hgrc is
used as a fallback.

See https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

diff -r 1f51b4658f21 -r 699fb7d08bdf mercurial/help/config.txt
--- a/mercurial/help/config.txt Thu Feb 02 14:19:48 2017 +0100
+++ b/mercurial/help/config.txt Tue Feb 07 17:33:35 2017 +0100
@@ -55,6 +55,8 @@
   On Unix, the following files are consulted:
 
   - ``/.hg/hgrc`` (per-repository)
+  - ``$XDG_CONFIG_HOME/hgrc`` (per-user)
+  - ``$HOME/.config/hgrc`` (per-user)
   - ``$HOME/.hgrc`` (per-user)
   - ``/etc/mercurial/hgrc`` (per-installation)
   - ``/etc/mercurial/hgrc.d/*.rc`` (per-installation)
diff -r 1f51b4658f21 -r 699fb7d08bdf mercurial/scmposix.py
--- a/mercurial/scmposix.py Thu Feb 02 14:19:48 2017 +0100
+++ b/mercurial/scmposix.py Tue Feb 07 17:33:35 2017 +0100
@@ -41,7 +41,15 @@
 if pycompat.sysplatform == 'plan9':
 return [encoding.environ['home'] + '/lib/hgrc']
 else:
-return [os.path.expanduser('~/.hgrc')]
+xdg = encoding.environ.get("XDG_CONFIG_HOME")
+if xdg is not None:
+return [os.path.join(xdg, "hgrc")]
+else:
+cfg = os.path.expanduser("~/.config/hgrc")
+if os.path.isfile(cfg):
+return [cfg]
+else:
+return [os.path.expanduser('~/.hgrc')]
 
 def termsize(ui):
 try:
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel