[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