hghave: add has_git_range for testing if git understands ext::sh Even on CentOS 7, git is at version 1.8. It seems git 1.9 is when ext::sh was introduced so we a check for that. The way these functions are written follows the same style and format for the way we check svn and bzr versions.

rebase: rewrite "x in y.children()" as "y in x.parents()" children() is slow

shelve: rewrite "x in y.children()" as "y in x.parents()" children() is slow

py3: use open() instead of file() constructor The file() constructor has been removed in python 3.

py3: convert keys of kwargs back to bytes using pycompat.byteskwargs()

py3: use pycompat.strkwargs() to convert kwargs keys to str before passing

py3: use '%d' instead of '%s' for integers Python 3 does not let you use '%s' for integers.

py3: pass the path in hg.repository() as bytes This make test-ancestor.py pass on Python 3.

py3: pass range() into list() to get one explicitly range() on python 3 returns a generator whereas on python 2 returns a list. So to get a list on python 3, we passed it into list()

check-concurrency: expose the feature as 'concurrent-push-mode' We move the feature to a proper configuration and document it. The config goes in the 'server' section because it feels like something the server owner would want to decide. We pick and open field because it seems likely that other checking levels will emerge in the future. (eg: server like the mozilla-try server will likely wants a "none" value) The option name contains 'push' since this affects 'push' only. The option value 'check-related' is preferred over one explicitly containing 'allow' or 'deny' because the client still have a strong decision power here. Here, the server is just advising the client on the check mode to use.