- 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.
