rebase: fix two ui.logs to actually have text when using default blackbox log
Some implementations of ui.log record structured information along with the
ui.log which can be used for metrics, but ui.log() as implemented by the
blackbox logging does not do anything special with this, and we end up with a
log line with no text (not even a line break) so it ends up looking something
like:
date time user @node (pid) [rebase]> date time user @node (pid) ...
Differential Revision: https://phab.mercurial-scm.org/D5279
wireprotov2server: let repo.narrowmatch(match) do matcher intersection
This is supported since
4fd0fac48922 (localrepo: allow narrowmatch()
to accept matcher to intersect with, 2018-09-28).
Differential Revision: https://phab.mercurial-scm.org/D5281
blackbox: extract function to test if log event is tracked
This will be a required method of the logger interface.
blackbox: initialize inlog flag properly
And ditch the "bb" prefix as it's no longer a ui extension class.
blackbox: initialize repo attribute properly
And ditch the "bb" prefix as it's no longer a ui extension class.
blackbox: extract logger class from ui wrapper
This moves most functions to new blackboxlogger class. The ui wrapper will
be removed later.
blackbox: rename variables to prepare extracting core logic from ui wrapper
I'm going to add ui.setlogger() function so that I can enable logging feature
in command server without extending ui.__class__. This prepares for it.
"self" will be a logger instance, so this patch renames some of them to "ui".
sparse-revlog: rework the way we enforce chunk size limit
We move from a O(N) algorithm to a O(log(N)) algorithm.
The previous algorithm was traversing the whole delta chain, looking for the
exact point where it became too big. This would result in most of the delta
chain to be traversed.
Instead, we now use a "binary" approach, slicing the chain in two until we
have a chunk of the appropriate size.
We still keep the previous algorithm for the snapshots part. There are few of
them and they are large bits of data distant from each other. So the previous
algorithm should work well in that case.
To take a practical example of restoring manifest revision '
59547c40bc4c' for
a reference NetBeans repository (using sparse-revlog). The media time of the
step `slice-sparse-chain` of `perfrevlogrevision` improve from 1.109 ms to
0.660 ms.