sapling/eden/scm/edenscm/hgext/fastannotate/support.py

155 lines
4.5 KiB
Python
Raw Normal View History

# Copyright (c) Facebook, Inc. and its affiliates.
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2.
# support: fastannotate support for hgweb, and filectx
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
from __future__ import absolute_import
from edenscm.mercurial import context as hgcontext, extensions, hgweb, patch, util
from . import context, revmap
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
class _lazyfctx(object):
"""delegates to fctx but do not construct fctx when unnecessary"""
def __init__(self, repo, node, path):
self._node = node
self._path = path
self._repo = repo
def node(self):
return self._node
def path(self):
return self._path
@util.propertycache
def _fctx(self):
return context.resolvefctx(self._repo, self._node, self._path)
def __getattr__(self, name):
return getattr(self._fctx, name)
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
def _convertoutputs(repo, annotated, contents):
"""convert fastannotate outputs to vanilla annotate format"""
# fastannotate returns: [(nodeid, linenum, path)], [linecontent]
# convert to what fctx.annotate returns: [((fctx, linenum), linecontent)]
results = []
fctxmap = {}
annotateline = getattr(hgcontext, "annotateline", None)
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
for i, (hsh, linenum, path) in enumerate(annotated):
if (hsh, path) not in fctxmap:
fctxmap[(hsh, path)] = _lazyfctx(repo, hsh, path)
# linenum: the user wants 1-based, we have 0-based.
lineno = linenum + 1
fctx = fctxmap[(hsh, path)]
line = contents[i]
if annotateline is None:
results.append(((fctx, lineno), line))
else:
# 2e32c6a31cc7 introduced annotateline
results.append((annotateline(fctx=fctx, lineno=lineno), line))
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
return results
def _getmaster(fctx):
"""(fctx) -> str"""
return fctx._repo.ui.config("fastannotate", "mainbranch") or "default"
def _doannotate(fctx, follow=True, diffopts=None):
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
"""like the vanilla fctx.annotate, but do it via fastannotate, and make
the output format compatible with the vanilla fctx.annotate.
may raise Exception, and always return line numbers.
"""
master = _getmaster(fctx)
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
annotated = contents = None
with context.fctxannotatecontext(fctx, follow, diffopts) as ac:
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
try:
annotated, contents = ac.annotate(
fctx.rev(), master=master, showpath=True, showlines=True
)
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
except Exception:
ac.rebuild() # try rebuild once
fctx._repo.ui.debug(
"fastannotate: %s: rebuilding broken cache\n" % fctx._path
)
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
try:
annotated, contents = ac.annotate(
fctx.rev(), master=master, showpath=True, showlines=True
)
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
except Exception:
raise
assert annotated and contents
return _convertoutputs(fctx._repo, annotated, contents)
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
def _hgwebannotate(orig, fctx, ui):
diffopts = patch.difffeatureopts(
ui, untrusted=True, section="annotate", whitespace=True
)
return _doannotate(fctx, diffopts=diffopts)
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
def _fctxannotate(
orig, self, follow=False, linenumber=False, skiprevs=None, diffopts=None
):
if skiprevs:
# skiprevs is not supported yet
return orig(self, follow, linenumber, skiprevs=skiprevs, diffopts=diffopts)
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
try:
return _doannotate(self, follow, diffopts)
except Exception as ex:
self._repo.ui.debug(
"fastannotate: falling back to the vanilla " "annotate: %r\n" % ex
)
return orig(self, follow, linenumber, skiprevs=skiprevs, diffopts=diffopts)
def _remotefctxannotate(
orig,
self,
follow=False,
linenumber=None,
skiprevs=None,
diffopts=None,
prefetchskip=None,
):
# skipset: a set-like used to test if a fctx needs to be downloaded
skipset = None
with context.fctxannotatecontext(self, follow, diffopts) as ac:
skipset = revmap.revmap(ac.revmappath)
return orig(
self,
follow,
linenumber,
skiprevs=skiprevs,
diffopts=diffopts,
prefetchskip=skipset,
)
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
def replacehgwebannotate():
extensions.wrapfunction(hgweb.webutil, "annotate", _hgwebannotate)
fastannotate: support replacing fctx.annotate directly Summary: Previously, I have performance concern about the signature of `fctx.annotate`: it returns fctxs, not ideal for performance since my initial goal is to get rid of reading revlogs in the best case. And letting the low-level `fctx.annotate` have some side effects writing to the disk is not that pretty. Because of that, fastannotate had re-invent part of the formatter (also optimized for performance somehow), and still cannot support all the features the original annotate supports, namely, templates. Now it makes sense to just replace `fctx.annotate` with a sub-optimal implementation, just for the flexibility of the template support of the original annotate command. We can use a "fake" or "lazy" fctx object to minimal the performance impact when people only need to print changeset nodes and line numbers - in which case we don't read revlog. Actually, the hgweb support already did a similar thing - converting fastannotate output to annotate output. So we can reuse some code. The next planned steps are: - Make the original "annotate" command aware of fastannotate protocol, do the pre-download stuff (downloading cache files at `fctx.annotate` is possible but inefficient because of not being batched). - "fastannotate" command remains a separated command optimized for perf and provides extra features like "--deleted". Because of the plan, the "commands" option does not make much sense - "fastannotate" command will not replace "annotate" directly thus dropped from the config interface. A new "modes" config option is added to control how fastannotate works. Test Plan: Modified existing tests Reviewers: #sourcecontrol, simonfar Reviewed By: simonfar Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4238998 Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
def replacefctxannotate():
extensions.wrapfunction(hgcontext.basefilectx, "annotate", _fctxannotate)
def replaceremotefctxannotate():
try:
r = extensions.find("remotefilelog")
except KeyError:
return
else:
extensions.wrapfunction(
r.remotefilectx.remotefilectx, "annotate", _remotefctxannotate
)