On 10/09/2018 18:21, Martin von Zweigbergk via Mercurial-devel wrote:
On Fri, Sep 7, 2018 at 8:09 AM Boris Feld <boris.f...@octobus.net
<mailto:boris.f...@octobus.net>> wrote:
# HG changeset patch
# User Boris Feld <boris.f...@octobus.net
<mailto:boris.f...@octobus.net>>
# Date 1536254177 14400
# Thu Sep 06 13:16:17 2018 -0400
# Node ID a4c3eb6c1a36cbbf64fa8930b173154b2e77ef2b
# Parent 9a18509c522deeb62a7b244dcf4c7b79a8dc1132
# EXP-Topic copy-perf
# Available At https://bitbucket.org/octobus/mercurial-devel/
# hg pull
https://bitbucket.org/octobus/mercurial-devel/ -r a4c3eb6c1a36
context: fix introrev to avoid computation as initially intended
diff --git a/mercurial/context.py b/mercurial/context.py
--- a/mercurial/context.py
+++ b/mercurial/context.py
@@ -829,6 +829,23 @@ class basefilectx(object):
# result is crash somewhere else at to some point.
return lkr
+ def _lazyrev(self):
We usually try to separate refactoring (like extracting a method) from
functional (or performance-related) changes. Could you do that with
this patch or does it not make sense for some reason?
In this case, the two changes are a bit too interleaved to be easily
split in two. We can't do the special casing until we have the new
method and the new method can't have any caller without changing the
conditionals to include the special casing.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel