lock: avoid unintentional lock acquisition at failure of readlock Acquiring lock by vfs.makelock() and getting lock holder (aka "locker") information by vfs.readlock() aren't atomic action. Therefore, failure of the former doesn't ensure success of the latter. Before this patch, lock is unintentionally acquired, if ENOENT causes failure of vfs.readlock() while 5 times retrying, because lock._trylock() returns to caller silently after retrying, and lock.lock() assumes that lock._trylock() returns successfully only if lock is acquired. In this case, lock symlink (or file) isn't created, even though lock is treated as acquired in memory. To avoid this issue, this patch makes lock._trylock() raise LockHeld(EAGAIN) at the end of it, if lock isn't acquired while retrying. An empty "locker" meaning "busy for frequent lock/unlock by many processes" might appear in an abortion message, if lock acquisition fails. Therefore, this patch also does: - use '%r' to increase visibility of "locker", even if it is empty - show hint message to explain what empty "locker" means

lock: avoid unintentional lock acquisition at failure of readlock Acquiring lock by vfs.makelock() and getting lock holder (aka "locker") information by vfs.readlock() aren't atomic action. Therefore, failure of the former doesn't ensure success of the latter. Before this patch, lock is unintentionally acquired, if self.parentlock is None (this is default value), and lock._readlock() returns None for ENOENT at vfs.readlock(), because these None are recognized as equal to each other. In this case, lock symlink (or file) isn't created, even though lock is treated as acquired in memory. To avoid this issue, this patch retries lock acquisition immediately, if lock._readlock() returns None "locker". This issue will be covered by a test added in subsequent patch, because simple emulation of ENOENT at vfs.readlock() easily causes another issue. "raising ENOENT only at the first vfs.readlock() invocation" is too complicated for unit test, IMHO.

httppeer: unify hint message for PeerTransportError Another raising PeerTransportError for "incomplete response" in httppeer.py uses this (changed) hint message. This unification reduces cost of translation.

revset: add i18n comments to error messages for followlines predicate This patch also includes un-quoting "descend" keyword for similarity to other error messages (this seems too trivial as a separated patch).

help: apply bulk fixes for indentation and literal blocking issues There are some paragraphs, which aren't rendered in online help as expected because of indentation and literal blocking issues. - hgext/rebase.py - paragraph before example code ends with ":", which treats subsequent indented paragraphs as normal block => replace ":" with "::" to treat subsequent paragraphs as literal block - help/pager.txt - paragraph before a list of --pager option values ends with "::", which treats subsequent indented paragraphs as literal block => replace "::" with ":" to treat subsequent paragraphs as normal block - the second line of explanation for no/off --pager option value is indented incorrectly (this also causes failure of "make" in doc) => indent correctly - help/revisions.txt - explanation following example code of "[revsetalias]" section isn't suitable for literal block => un-indent explanation paragraph to treat it as normal block - indentation of "For example" before example of tag() revset predicate matching is meaningless - descriptive text for tag() revset predicate matching isn't suitable for literal block => un-indent concatenated two paragraphs to treat them as normal block

rebase: fix incorrect configuration example This configuration example doesn't make rebase require a destination, even though help document wants to show such example.

help: use hg role of mini reST to make hyper link in HTML page

help: use mercurial as a subject of colorization and pagination Now, colorization and pagination are in Mercurial core.

packaging: add make target for linux wheels Having linux wheels is going to helps system without compiler or python-dev plus speed up the installation for everyone. I followed the manylinux example repository https://github.com/pypa/python-manylinux-demo to add a make target (build-linux-wheels) using official docker image to build python 2 linux wheels for mercurial. It generates Python 2.6 and Python 2.7 for both 32 and 64 bits architectures. I had to blacklist several test cases for various reasons: * test-convert-git.t and test-subrepo-git.t because of the git version * test-patchbomb-tls.t because of warning using tls 1.0 It's likely because the docker image is based on centos 5.0 and openssl is outdated.

tests: fix two http tests to also pass inside manylinux1 docker This will let us build Linux wheels.