lock: use util.unlink (issue2537)

reintroduces util.unlink, for POSIX and Windows. windows: factor it out of rename posix: add alias 'unlink' for os.unlink Note that this new unlink function now has different semantics than the unlink() we had before changeset 6bf39d88c857 ("rename util.unlink to unlinkpath").

opener: check exception for ENOENT

windows.rename: check OSError for EEXIST For example, if src has been opened with Python's open(), os.rename will raise EACCES. Continuing in that case is pointless.

perf: restore lazyindex hack This hack (and the module it lives in) exist so that performance can be compared across different hg versions.

revlog: pass rev to _checkhash

revlog: incrementally build node cache with linear searches This avoids needing to prime the cache for operations like verify which visit most or all of the index.

bundlerepo: use less intrusive util.posixfile to open bundle

osutil: treat open modes 'w' and 'a' as 'w+' and 'a+' in posixfile to work around http://support.microsoft.com/kb/899149. Also, Microsoft's documentation of the CreateFile Windows API says (quote): When an application creates a file across a network, it is better to use GENERIC_READ | GENERIC_WRITE for dwDesiredAccess than to use GENERIC_WRITE alone. The resulting code is faster, because the redirector can use the cache manager and send fewer SMBs with more data. This combination also avoids an issue where writing to a file across a network can occasionally return ERROR_ACCESS_DENIED.

move tags.cache and branchheads.cache to a collected cache folder .hg/cache/ The generation of cache files like tags.cache and branchheads.cache is not an actual reflection of things changing in the whole of the .hg directory (like eg a commit or a rebase or something) but instead these cache files are just part of bookkeeping. As such its convienant to allow various clients to ignore file events to do with these cache files which would otherwise cause a double refresh. Eg one refresh might occur after a commit, but the act of refreshing after the commit would cause Mercurial to generate a new branchheads.cache which would then cause a second refresh, for clients. However if these cache files are moved into a directory like eg .hg/cache/ then GUI clients on OSX (and possibly other platforms) can happily ignore file events in this cache directory.

addchangegroup: document the current locking semantics

keyword: update documentation for kwshrink * remove obsolete reference to potential problems with merge and import * emphasize that running kwshrink before configuration changes which affect active/expanded keywords is mandatory

tests: remove duplication of the CGI environment variables

revlog: explicit test and explicit variable names