manifestmerge: fix order in which manifests are fetched
If the manifest of an earlier revision on the same delta chain is read before
that of a later revision, the revlog remembers that we parsed the earlier
revision and continues applying deltas from there onwards. If manifests are
parsed the other way round, we have to start over from the fulltext.
For a fresh clone of mozilla-central, updating from
29dd80c95b7d to its parent
aab96936a177 requires approximately 400 fewer zlib.decompress calls, which
results in a speedup from 1.10 seconds to 1.05.
merge: run _forgetremoved after manifestmerge
_forgetremoved can trigger manifest construction, but we only want it to
happen after manifestmerge, so that our attempt to read the manifests in the
right order in an upcoming patch actually works.
dirstate: disable gc while parsing the dirstate
This prevents a performance regression an upcoming patch would otherwise
introduce because it indirectly delays parsing the dirstate a bit.
export: show 'Date' header in a format that also is readable for humans
'export' is the official export format and used by patchbomb, but it would only
show date as a timestamp that most humans might find it hard to relate to. It
would be very convenient when reviewing a patch to be able to see what
timestamp the patch will end up with.
Mercurial has always used util.parsedate for parsing these headers. It can
handle 'all' date formats, so we could just as well use a readable one.
'export' will now use the format used by 'log' - which is the format described
as 'Unix date format' in the templating help. We assume that all parsers of '#
HG changeset patch'es can handle that.
factotum: fix urllib2 import so it no longer relies on a demandimport bug
demandimport will do that urllib2 can be imported 'from mercurial' even though
it doesn't exist there.
hgweb: make the test suite use hgweb in a more WSGI compliant way
- as checked by wsgiref.validate.
This makes sure that we don't optimize hgweb for invalid use cases.
bundlerepo: replace basemap with the base field in the index
Bundle revisions had some info in their fake revlog intries and some info in a
dict with all the bundle revisions. This dict was used to get the stored data
and to distinguish repo revisions from bundle revisions.
Real repo revisions and bundle revisions will now be distinguished by comparing
with the tip revision of the original repo. This reintroduces something similar
to disktiprev which was unused and removed in
a928865b4a4f and let that replace
the O(reposize) dict.
profiling: replace '+' markup of nested lines with indentation
The display of nested lines for hg --profile was very non-obvious and made it
look like sort didn't work.
The '+' immediately before CallCount was not related to the CallCount and did
not mean plus in any integer sense.
The '+' before module looked like a part of the module name and not like ascii
art.
Instead we now indent the subordinate module names to clearly show the
structure.
merge: don't fiddle with name lookups or i18n in hot loops
We perform attribute dereferences and i18n lookups before looping.
merge: apply non-interactive working dir updates in parallel
This has a big effect on the performance of working dir updates.
Here are the results of update from null to the given rev in several
repos, on a Linux 3.2 system with 32 cores running ext4, with the progress
extension enabled.
repo rev plain parallel speedup
hg
7068089c95a2 0.9 0.3 3
mozilla-central
fe1600b22c77 42.8 7.7 5.5
linux-2.6
9ef4b770e069 31.4 4.9 6.4