The subprocess module is not thread safe. Spawning a thread to read
the output leads to exceptions like this when Mercurial exits:
Exception exceptions.TypeError: TypeError("'NoneType' object is not
callable",) in <bound method Popen.__del__ of <subprocess.Popen
object at 0x9ed0dcc>> ignored
The bug is already reported in the Python bug tracker:
http://bugs.python.org/issue1731717
Some modules (like revlog) would import util.sha1 as _sha1. This
defeats the purpose of having util.sha1 overwrite itself with a faster
version -- revlog would end up always calling the slow version. By
always delegating to util._fastsha1 we avoid this at the cost of an
extra (but unconditional) indirection.
This adds a change to the way that abort is processed, as it will not continue
truncating files beyond the first failure, otherwise the respective
functionality is maintained, i.e. abort will not unlink files, but rollback
will.
Co-contributor: Sune Foldager <cryo@cyanite.org>
Previously, accessing the filelinkrevs of a specific file that happens to
have already been unlinked from the filesystem, e.g. due to a partial rollback
having occurred, will trigger a KeyError being raised.
Co-contributor: Sune Foldager <cryo@cyanite.org>
All transactional methods on the transaction class have had a decorator
added that ensures the transaction is running.
Co-contributor: Sune Foldager <cryo@cyanite.org>
Use a temporary file name as target for a forced rename on Windows. The
target file name is not opened at any time; just renamed into and then
unlinked. Using a temporary instead of a static name is necessary since
otherwise a hg crash can leave the file lying around, blocking future
attempts at renaming.
Use ampersands (&) to delineate the response char in each choice.
ui.prompt() responses are now explicitly case insensitive. GUIs
that subclass ui can generate dialogs from the full choice names.
The bzr converter maintains a child -> parents mapping and drop entries
whenever a child is read. It does not work with filemaps, getchangedfiles() may
be called more than once when filtered files belong to merge revisions.
getchanges() still works that way but it is not clear whether a similar issue
can arise when interacting with merges.
