[PATCH] commit: add config option to limit copy search distance

[Durham Goode]

On 12/17/14 5:29 PM, Matt Mackall wrote:
> On Wed, 2014-12-17 at 17:11 -0800, Ryan McElroy wrote:
>> # HG changeset patch
>> # User Ryan McElroy <rmcelroy at fb.com>
>> # Date 1418862573 28800
>> #      Wed Dec 17 16:29:33 2014 -0800
>> # Node ID 769728b7e5f243b0527d6f374098c537f9ddd2d6
>> # Parent  39cead85fd58ae6693592074656b284ed736d9bc
>> commit: add config option to limit copy search distance
>>
>> Editing history, among other things, can result in a copy source 'going missing'
>> which causes Mercurial to search back through history for the original of the
>> file. This search may be in vain, though, because the source of the file is no
>> longer in the history. In large repositories, this can take hours or days.
>>
>> This patch adds an optional configuration option (limit.copysearchrevs) to limit
>> how far back Mercurial will search for the file. A value of None (default) will
>> maintain the current behavior of searching all the way back while a value of 0
>> will disable search through any revs. Moderate values should enable the benefits
>> of this behavior in most cases while avoiding long delays searching through the
>> history.
> Interesting that at the same time we have a patch on the list that
> propose removing the limit entirely.
>
I think this is a different issue.  The _tracelimit discussion in the 
other thread is about traversing the filelog, while the stuff Ryan is 
changing is actually traversing the entire changelog.

I don't understand the copy tracking code even before Ryan's change.  
It's basically saying "if the copy source isn't in either of the 
dirstate parent manifests, go looking for it".  But if the file being 
copied isn't in either of the parents, why are we treating it as a copy?

Further more, why are we even searching for the copy node?  Doesn't the 
copy data returned by fctx.renamed() give us the exact copy source path 
and copy source file node?  It looks like memfilectx doesn't obey this, 
but that's probably fixable.

I'll play around with this a bit to see if my theory holds out.