docs: describe ui.color consistently with --color The --color option is described to accept "boolean, always, auto, never, or debug". Let's use a similar description for ui.color. Also fix the formatting to use double quotes as we seem to use for about half the values in config.txt (the other half uses double backticks). Also use uppercase Boolean for consistency within the file.

test: glob out variation from 'HGPORT' length On system where HGTEST_PORT is configured to a value an order a magnitude lower or higher than the default. The number of digit in the HGPORT changes and this test breaks.

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.