[PATCH 2 of 2 stable v2] copies: drop _tracefile limit when finding copy sources in actx manifest
Mads Kiilerich
mads at kiilerich.com
Mon Dec 15 18:57:59 CST 2014
On 12/15/2014 11:26 PM, Matt Mackall wrote:
> On Thu, 2014-12-11 at 21:27 +0100, Mads Kiilerich wrote:
>> # HG changeset patch
>> # User Mads Kiilerich <madski at unity3d.com>
>> # Date 1418329283 -3600
>> # Thu Dec 11 21:21:23 2014 +0100
>> # Branch stable
>> # Node ID 0fcb69be20206cfe1582244afd93185f2c056e91
>> # Parent 837f7c70551db57aef3a80dac4b50129bb647529
>> copies: drop _tracefile limit when finding copy sources in actx manifest
> FYI, I'm sitting on this until I have several hours to think about it,
> as this will be a pretty big performance problem for some people.
Yes, I figure that would be the potential worst case for a change like this.
But as I tried to argue, I think it only will be a problem if a fctx
with a very long ancestor chain is merged into a very short diff range
... and the long chain will only be wrong if a file that lived in the
past but is removed in actx somehow is restored in the diff range so the
fctx iteration will visit actx ancestors. The question is how big the
performance problem will be and for how many people ... and whether it
is necessary / worth it for correctness.
I guess a similar scenario can happen with different order in changelog
and filelog and thus not just can be filed under "we know linkrev
sometimes cause malfunction" but also must be filed under "consequences
of history modification".
/Mads
More information about the Mercurial-devel
mailing list