Because revsets query is evaluated lazily, "list(revs)" may take long for
complicated query. So we shouldn't iterate revs many times. This patch is the
easiest workaround for the issue4782. We could introduce more aggressive
caching, but it wouldn't be as fast as the simple baseset operation.
Gregory Szorc said "this makes `hg wip` on my Firefox clone ~4x faster than
3.5.1 (~6.5s to ~1.5s). This is after a regression in @ to ~45s."
Not only does this defeat the purpose of having `branchgroupiter` an iterable, but
this also makes revs something else than a smartset preventing to use revs.min()
in the call to reachablerevs.
This patch is part of a series of patches to speed up the computation of
revset.reachableroots by introducing a C implementation. The main motivation
is to speed up smartlog on big repositories. At the end of the series, on our
big repositories the computation of reachableroots is 10-50x faster and
smartlog on is 2x-5x faster.
Before this patch, we had a custom computation for grandparent that was very
close to the idea of reacheablerooots. This patch expresses grandparent with
reachableroots to reduce the amount of code.
Instead of just bootstrapping the algorithm with the first revision we
see, allow callers to pass revs that should be displayed first. All
branches are retained until we can display such revision.
Expected usage is to display the current working copy parent first.
The algorithm now works when some revisions are skipped. We now use "first
included ancestors" instead of just "parent" to link changesets with each other.
We are going to add an additional layer of indentation to support non-contiguous
revset. We do it in a pure code movement changeset to help the readability of
the next changeset.
We add an experimental config option to use the topological sorting. I first
tried to hook the 'groupbranchiter' function in the 'sort' revset but this was useless
because graphlog enforces revision number sorting :(
As the goal is to advance on the topological iteration logic, I see this
experimental option as a good way to move forward.
We have to use turn the iterator into a list because the graphlog is apparently
not ready for pure iterator input yet.
This changeset introduces a function to perform topological (one branch after
the other) iteration over a set of changesets. This first version has a lot of
limitations, but the approach should be flexible enough to allow many
improvements in the future. This changeset aims to set the first stone more
than providing a complete solution.
The algorithm does not need to know the whole set of nodes involved
before emitting revision. This makes it a good candidate for usage in place
like `hg log` or graphical tools that need a fast first result time.
- Avoid flipping lineWidth state around the edge() call, pass it to the
function instead.
- Pass the line width and color appended to the other parameters instead of in
a dictionary. The javascript code is simpler, no need to check for all
containers existence, and the JSON output is smaller.
- Reindent setColor() comments and fix code spacing.
Before, we'd lookup the branch for every edge segment in the entire
graph: extremely expensive. This happened even when no per-branch
settings existed.
Now we define a revision -> config cache function that's LRU-cached
and is a no-op when no configuration exists. Still not terribly fast,
but hopefully only one real branch lookup per revision. This might
degenerate for wide graphs as the LRU is hard-coded to 20 elements.
Our goal is not to strictly disallow _invalid_ input, simply disallow _hostile_ input.
Avoid using re
Avoid creating empty dicts when no branch parameters are recognized
You can specify color to visually distinguish main branch (trunk)
on hgweb's graph page. If color specified, all branch heads will share
same color. Settings format is branch_name.color = value, where color
is six hexadecimal digits e.g.:
[graph]
default.color = FF0000
You can specify width to visually distinguish main branch (trunk)
on hgweb's graph page. Settings format is branch_name.width = value,
where width in px e.g.:
[graph]
default.width = 3
The grandparent() function was returning only the closest predecessor of a
missing parent while it must return all of them to display a correct ancestry
graph.
a32a0f72065a introduced the ability to walk the DAG
given arbitrary revisions, but changed the behaviour of
it to return a list of all nodes (and create a changectx
for each one) rather than doing it lazily.
This has a pretty significant impact on performance for large
repositories (tested on CPython repo, with output disabled):
$ time hg glog
real 0m2.642s
user 0m2.560s
sys 0m0.080s
Before a32a0f72065a:
$ time hg glog
real 0m0.143s
user 0m0.112s
sys 0m0.032s
And after this fix:
$ time hg glog
real 0m0.213s
user 0m0.184s
sys 0m0.028s
Thanks for the idea and most of the implementation to Klaus Koch
Backs revisions() and filerevs() with DAG walker which can iterate through
arbitrary list of revisions instead of strict one by one iteration from start to
stop. When a gap occurs in a revisions (i.e. in file log), the next topological
parent within the revset is searched and the connection to it is printed in the
ascii graph.
File graph can draw sometimes more connections than previous version, because
graph is produced according to the revset, not according to a file's filelog.
In case the graph contains several branches where the left parent is null, the
graphs for each are printed sequentially, not in parallel as it was a case
earlier (see for example the graph for README in hg-dev).
While this situation should never under normal use, some real
life repos sometimes contain such changesets (older hg versions,
broken rebases, etc...)
hgweb was displaying an "Internal error" in this case, and graphlog
displayed a redundant branch all the way to null: it does not cost us
much to just ignore this extra parent when constructing the DAG.
Limit was interpreted as absolute, from the topmost revision, without
counting the number of revisions matching a given file.
Which caused "glog -lN file" to show sometimes less than N csets if
the file was not modified in all of the N previous csets.
glog will now match the behavior of log.
Changes graph() to colorededges(), which operates on the new
generic DAG walks and adds color and edge information needed
by the web graph.
This is in preparation of adding DAG walk filters, like the
linear run collapser in the next patch. The idea is to have
a bunch of changelog walkers that return basic data. Then we
can filter this data. Finally we add edge and formatting info
suitable for the output media we want to target (glog, hgweb).
Semantically, it is better to use None over any other value when there is
"no value". Using maxint in this context is quite hackish, and is not forward
compatible.
