[PATCH 4 of 4] copy: add flag for disabling copy tracing

Durham Goode durham at fb.com
Tue Feb 3 21:07:09 CST 2015


On 2/3/15 8:50 AM, Pierre-Yves David wrote:
>
>
> On 02/03/2015 03:20 AM, Durham Goode wrote:
>> # HG changeset patch
>> # User Durham Goode <durham at fb.com>
>> # Date 1422386787 28800
>> #      Tue Jan 27 11:26:27 2015 -0800
>> # Node ID 39427c27d17d5d13bbe24367d458705dd9a6d64a
>> # Parent  7c2e0203750f9372d77c374ce931e0bb87a54f0f
>> copy: add flag for disabling copy tracing
>
> I believe the main motivation for this patch was extremely inflated by 
> a performance regression in 3.3-rev. Now that the regression is fixed 
> I think it would be wiser to not disable this important Mercurial 
> feature.
>
I just tried it with the latest @ build and the perf has not gotten any 
better (https://bpaste.net/show/b5cbdcab2d47).  The perf win is so big 
that I'd like to experiment with disabling it and see how many users 
complain.  Then we can iterate to find a nice balance (better detection 
with lazymanifest + maybe issue a warning if we think we're losing copy 
information).

The trace copies algorithm is fundamentally not scalable for a large 
working copy (it traces the history of every file that has changed since 
the common ancestor).  It simply cannot operate on a large repo without 
either having forward pointers (i.e. tracing copies forward from the 
common ancestor up to the rebase destination), or a remote server that 
can answer copy questions quickly.  Since neither solution is easy, and 
the perf win so significant, I'd rather disable the feature, and allow 
users to reenable it when they need it.


More information about the Mercurial-devel mailing list