The radix tree already contains all the information we need to
determine whether a short string is an unambiguous node identifier.
We now make use of this information.
In a kernel tree, this improves the performance of
"hg log -q -r24bf01de75" from 0.27 seconds to 0.06.
Since f7e538c3b7ba, if a chunk starts with "@@ -0,1", oldstart turns into
a negative value. Because diffhelpers.testhunk() doesn't expect negative bstart,
it bypasses "alen > blen - bstart" condition and segfaults at
"PyList_GET_ITEM(b, i + bstart)".
Before this, if advanceboundary() failed after updating some roots but
before calling retractboundary(), the phase cache would be left in an
invalid state, marked dirty, and written as such. This patch approach is
to turn advance/retractboundary() into phasecache methods, then operate
on copies and merge them back on success.
With the same technique, we can ensure the atomicity of combinations of
advance/retractboundary() calls, like those performed in changegroup
handling code.
The original motivation was changectx.phase() had special logic to
correctly lookup in repo._phaserev, including invalidating it when
necessary. And at other places, repo._phaserev was accessed directly.
This led to the discovery that phases state including _phaseroots,
_phaserev and _dirtyphase was manipulated in localrepository.py,
phases.py, repair.py, etc. phasecache helps encapsulating that.
This patch replaces all phase state in localrepo with phasecache and
adjust related code except for advance/retractboundary() in phases.
These still access to phasecache internals directly. This will be
addressed in a followup.
When:
[mq]
check = True
is set, qpush, qpop and qgoto behave as if -c/--check were passed. If
incompatible options like -f/--force or --exact are set, this setting is
ignored.
This setting enables what many users expect mq default behaviour to be.
qpush help says the following about --force:
1- When -f/--force is applied, all local changes in patched files will
be lost.
2- Apply on top of local changes
In practice, qpush --force will attempt to apply the patch on top of
local changes, and on success will merge them in the pushed patch. On
failure, patched files will contain a mix of local changes (where the
patch could not apply) and a mix of patch changes (were it applied). So,
local changes are less lost than entangled with a mass of other changes.
This patch makes qpush --force backup all locally modified files touched
by the next patch being applied. When multiple patches are being pushed,
this logic is repeated for each patch. Note that modified but
successfully patched files are preserved as well.
With the pager running as a child process, exiting the pager doesn't
result in a broken pipe message. To distinguish the exit broken pipe code
from a mercurial abort we register the default action for SIGPIPE. This
results in a 141 exit code instead of a 255. On windows SIGPIPE doesn't
exists and a ValueError will be thrown.
This changes how the pager extension invokes the pager. Prior to this change,
the extension would fork Hg and exec the pager in the parent process. This
loses Hg exit code, and it doesn't work on Windows.
Now the pager is invoked using the subprocess library, and an atexit handler is
registered that makes Hg wait for the pager to exit before it exits itself.
Note that if you exit the pager before Hg is done running, you'll get an exit
code of 255, which is caused by Python blowing up due to a broken pipe. If you
set pager.quiet=True, you'll get the OS-level return code of 141.
Since docutils 0.9, `roman` module has been moved from module directory root
(i.e. `site-packages/roman.py`) to `docutils.utils` module. Therefore `import
roman` statement should be wrapped in `try: ... except ImportError: ...` block
to handle importing correctly.
Commands working without a repository, like "init", are listed in
commands.norepo. Commands optionally using a repository, like "showconfig", are
listed in commands.optionalrepo. Command aliases were inheriting the former but
not the latter.
As detailed on http://docs.python.org/extending/newtypes.html (quote):
"In this case, we can just use the default implementation provided by the API
function PyType_GenericNew(). We’d like to just assign this to the
tp_new slot, but we can’t, for portability sake. On some platforms or
compilers, we can’t statically initialize a structure member with a function
defined in another C module, so, instead, we’ll assign the tp_new slot in the
module initialization function just before calling PyType_Ready()."
Fixes "gcc (GCC) 3.4.5 (mingw-vista special r3)" complaining with:
mercurial/parsers.c:1096: error: initializer element is not constant
mercurial/parsers.c:1096: error: (near initialization for `indexType.tp_new')
brendan mentioned on IRC that b64decode raises a TypeError too, but while the
previous exception type may be better in general, it is much easier to make it
behave like the related C code and changes nothing for mercurial itself.
When we encounter a corrupt index, we "fail" the init but our
destructor still gets called. On some systems, this was causing us to
attempt to decref a dangling to self->data.
