[PATCH 2 of 2 stable v2] copies: drop _tracefile limit when finding copy sources in actx manifest

[Pierre-Yves David]

On 12/29/2014 02: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
>
> Pierre-Yves tells me he's hot on the trail for a fix for this (but is
> also sick so hasn't finished his patches). Going to drop this for now.

So looking closer to the test case in the first patch of this series, I 
discovered that the merge itself was not the source of the issue. And 
that good old linkrev-shadowing bug was making the rename detection fails.

Re-using some of the idea Matt brought up in december, I poke at solving 
this kind of linkrev-induced misbehavior. I think I come with a 
performance acceptable solution that have been patchbombed on the list.

One of the patch contains the reduced version of your original test 
case. Check the addition to 
http://www.selenic.com/pipermail/mercurial-devel/2014-December/065080.html 
at the very end of this email:

	http://www.selenic.com/pipermail/mercurial-devel/2014-December/065080.html

However, showing that linkrev have bug does not prove that rename + 
merges is not buggy. So I tested various cases that looked pathological 
to me and could not get anything failing in a way similar to want I 
understand of this series. The short version is that any merge that 
involved file rename on one side will result in the creation of a new 
file revision duplication the rename information. So throwing more 
merges in the mixes did not made the situation more complicated. I can 
excavate my tests if someone is interested.

In the process I found a merge + rename related bugs, but it was 
actually already fixed: http://bz.selenic.com/show_bug.cgi?id=3908

-- 
Pierre-Yves David