Apparently the "import x as xy" doesn't manage to update xy in the
current scope's dictionary after load, which causes nodemod.nullrev to do a huge amount of demandload magic in the inner loop.
This greatly speeds up node->rev lookups, with results that are
often user-perceptible: for instance, "hg --time log" of the node
associated with rev 1000 on a linux-2.6 repo improves from 0.3
seconds to 0.03. I have not found any instances of slowdowns.
The new perfnodelookup command in contrib/perf.py demonstrates the
speedup more dramatically, since it performs no I/O. For a single
lookup, the new code is about 40x faster.
These changes also prepare the ground for the possibility of further
improving the performance of prefix-based node lookups.
This solves a similar problem than the previous --follow/--rev patch. This time
we need changelog.ancestors()/descendants() filtering on first parent.
Duplicating the code looked better than introducing keyword arguments. Besides,
the ancestors() version was already implemented in follow() revset.
The previous behaviour of --follow was really a subset of what is really
happening in log command:
- If --rev is not passed, default to '.:0'
- Resolve --rev into a revision list "revs"
- Set the starting revision to revs[0]
- If revs[1] > revs[0] keep descendants(revs[0]) in revs, otherwise keep
ancestors.
Running:
$ time hg debugrevspec 'user(mpm)' | wc
on Mercurial repository takes 1.0s with a regular version and 1.8s if
commands.debugrevspec() is patched to pass revisions to revset.match() from tip
to 0.
Depending on what we expect from the revset API and caller wisdom, we might
want to push this change in revset.match() later.
When --follow and --rev are passed, --follow actual behaviour depends on the
input revision sequence defined by --rev. If --rev is not passed, the default
revision sequence depends on the presence of --follow. It means the revision
sequence generation is part of log logic and must be wrapped. The issue
described above is fixed in following patches.
In my tests of an fncache containing 300,000 entries, this improves
read time from 567ms to 307, and write time from 1328ms to 533.
These numbers aren't so great, since the fncache file is only 17MB
in size, but they're an improvement.
This keyword can be used to find revisions that "match" one or more fields of a
given set of revisions.
A revision matches another if all the selected fields (description, author,
branch, date, files, phase, parents, substate, user, summary and/or metadata)
match the corresponding values of those fields on the source revision.
By default this keyword looks for revisions that whose metadata match
(description, author and date) making it ideal to look for duplicate revisions.
matching takes 2 arguments (the second being optional):
1.- rev: a revset represeting a _single_ revision (e.g. tip, ., p1(.), etc)
2.- [field(s) to match]: an optional string containing the field or fields
(separated by spaces) to match.
Valid fields are most regular context fields and some special fields:
* regular fields:
- description, author, branch, date, files, phase, parents,
substate, user.
Note that author and user are synonyms.
* special fields: summary, metadata.
- summary: matches the first line of the description.
- metatadata: It is equivalent to matching 'description user date'
(i.e. it matches the main metadata fields).
Examples:
1.- Look for revisions with the same metadata (author, description and date)
as the 11th revision:
hg log -r "matching(11)"
2.- Look for revisions with the same description as the 11th revision:
hg log -r "matching(11, description)"
3.- Look for revisions with the same 'summary' (i.e. same first line on their
description) as the 11th revision:
hg log -r "matching(11, summary)"
4.- Look for revisions with the same author as the current revision:
hg log -r "matching(., author)"
You could use 'user' rather than 'author' to get the same result.
5.- Look for revisions with the same description _AND_ author as the tip of the
repository:
hg log -r "matching(tip, 'author description')"
6.- Look for revisions touching the same files as the parent of the tip of the
repository
hg log -r "matching(p1(tip), files)"
7.- Look for revisions whose subrepos are on the same state as the tip of the
repository or its parent
hg log -r "matching(p1(tip):tip, substate)"
8.- Look for revisions whose author and subrepo states both match those of any
of the revisions on the stable branch:
hg log -r "matching(branch(stable), 'author substate')"
This change permits the transplant extension to operate on merge
changesets by way of --parent. This is particularly useful for
workflows which cherrypick branch merges rather than each commit
within a branch.
This can be selected using the config variable profiling.type or
the environment variable HGPROF ("ls" for the default, "stat" for
statprof). The only tuneable is the frequency, profiling.freq,
which defaults to 1000 Hz.
If statprof is not available, a warning is printed.
Some platforms, notably Plan 9 from Bell Labs are stuck on older
releases of Python. Due to restrictions in the platform, it is not
possible to backport the SSL library to the existing Python port.
This patch permits the UI to quiesce SSL verification warnings by
adding a configuration entry named reportoldssl to ui.
This improves the performance of "hg log -l1" from 0.21 seconds to
0.07 on a Linux kernel tree.
Ideally we could use xrange instead of range on the most common
path, and thus avoid a ton of allocation, but xrange doesn't support
slice-based indexing.
This patch contains support for Plan 9 from Bell Labs. A README is
provided in contrib/plan9 which describes the port in greater detail.
A new extension is also provided named factotum which permits the
factotum(4) authentication agent to provide credentials for HTTP
repositories. This extension is also applicable to other POSIX
platforms which make use of Plan 9 from User Space (aka plan9ports).
This change also fixes a nasty memory leak: previously, self->caches
was not being freed.
The new clearcaches method lets us benchmark with finer granularity,
as it lets us separate the cost of loading a revlog index from those
of populating and accessing the cache data structures.
'hg qnew' passes matching object to 'patch.diff()' to specify target
filenames, and it causes 'dirstate.walk()' via 'repo.status()' in
'patch.diff()'.
but target files are already known before 'patch.diff()' invocation.
to avoid useless 'dirstate.walk()' invocation, this patch uses
'changes' argument to pass already known target files to
'patch.diff()' instead of 'match' argument.
'changes' argument of 'patch.diff()' should have lists for modified,
added and removed files separately, so this patch saves status of
'.hgsubstate' before commit, and put it into appropriate list in
'changes'.
'hg qnew' with pattern/-I/-X creates matching object with them, and
uses it twice for 'dirstate.walk()': via 'repo.status()' and
'repo.commit()'.
this may cause full manifest scan in the second 'dirstate.walk()',
even though mq already knows complete target filenames at the first
'dirstate.walk()'.
this patch creates exact matching object also in this case, and use it
at 'repo.commit()' invocation to avoid full manifest scan in the
second 'dirstate.walk()'.
even though 'inclsubs' is added to 'pats' for original matching
object, it is also passed to exact matching object, because
subrepositories are deleted from result of 'dirstate.walk()' at the
end of it.
We only parse entries in a revlog index file when they are actually
needed, and cache them when first requested.
This makes a huge difference to performance on large revlogs when
accessing the tip revision or performing a handful of numeric lookups
(very common cases). For instance, "hg --time tip --template {node}"
on a tree with 300,000 revs takes 0.15 before, 0.02 after.
Even for revlog-intensive operations (e.g. running "hg log" to
completion), the lazy approach is about 1% faster than the eager
parse_index2.
Currently, the 'user' filter is using util.shortuser(text) (which clearly
doesn't extract only the user portion of an email address, even though the
help text says it does).
The new 'emailuser' filter uses the new util.emailuser(text) function which,
instead, does exactly that.
The help text on the 'user' filter has been modified accordingly.
