Previously, when updating, cachelfiles was called blindly on all largefiles
in the repository at the revision being updated to, despite the fact that
a list of which largefiles needs to be updated has already been collected. This
optimization constrains the cachelfiles call to only the largefiles that need
to be updated.
On a repository with about 80 largefiles, updating between two revisions that
only change one largefile goes from approximately 6.7 seconds to 3.3 seconds.
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.
Note that aborting in subrepo.state() prevents "repairing" commands like revert
to be issued. The user will have to edit the .hgsubstate manually (but he
probably had already otherwise this would not be failing). The same behaviour
already happens with invalid .hgsub entries.
Let R be a repo served by an hg daemon on a machine with an empty largefiles
cache. Pushing a largefiles repo to R will result in a no-such-file-or-directory
OSError because putlfile will attempt to create a temporary file in
R/.hg/largefiles, which does not yet exist.
This patch also adds a regression test for this scenario.
We allow rebase plus collapse, but not collapse only? I imagine people would
rebase first then collapse once they are sure the rebase is correct and it is
the right time to finish it.
I was reluctant to submit this patch for reasons detailed below, but it
improves rebase --collapse usefulness so much it is worth the ugliness.
The fix is ugly because we should be fixing the collapse code path rather than
the merge. Collapsing by merging changesets repeatedly is inefficient compared
to what commit --amend does: commitctx(), update, strip. The problem with the
latter is, to generate the synthetic changeset, copy records are gathered with
copies.pathcopies(). copies.pathcopies() is still implemented with merging in
mind and discards information like file replaced by the copy of another,
criss-cross copies and so forth. I believe this information should not be lost,
even if we decide not to interpret it fully later, at merge time.
The second issue with improving rebase --collapse is the option should not be
there to begin with. Rebasing and collapsing are orthogonal and a dedicated
command would probably enable a better, simpler ui. We should avoid advertizing
rebase --collapse, but with this fix it becomes the best shipped solution to
collapse changesets.
And for the record, available techniques are:
- revert + commit + strip: lose copies
- mq/qfold: repeated patching() (mostly correct, fragile)
- rebase: repeated merges (mostly correct, fragile)
- collapse: revert + tag rewriting wizardry, lose copies
- histedit: repeated patching() (mostly correct, fragile)
- amend: copies.pathcopies() + commitctx() + update + strip
Eliminates
mercurial/diffhelpers.c(143) : warning C4244: '=' : conversion from
'Py_ssize_t' to 'int', possible loss of data
mercurial/diffhelpers.c(144) : warning C4244: '=' : conversion from
'Py_ssize_t' to 'int', possible loss of data
when compiling for Windows x64 target using the Microsoft compiler.
Eliminates
mercurial/diffhelpers.c(81) : warning C4244: '=' : conversion from
'Py_ssize_t' to 'int', possible loss of data
mercurial/diffhelpers.c(82) : warning C4244: '=' : conversion from
'Py_ssize_t' to 'int', possible loss of data
when compiling for Windows x64 target using the Microsoft compiler.
Eliminates
mercurial/diffhelpers.c(23) : warning C4244: 'initializing' : conversion from
'Py_ssize_t' to 'int', possible loss of data
mercurial/diffhelpers.c(26) : warning C4244: 'initializing' : conversion from
'Py_ssize_t' to 'int', possible loss of data
mercurial/diffhelpers.c(27) : warning C4244: 'initializing' : conversion from
'Py_ssize_t' to 'int', possible loss of data
mercurial/diffhelpers.c(30) : warning C4244: 'initializing' : conversion from
'Py_ssize_t' to 'int', possible loss of data
when compiling for Windows x64 target using the Microsoft compiler.
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.
