[PATCH V6] copy: add flag for disabling copy tracing

[Durham Goode]

On 8/11/15 12:59 PM, Augie Fackler wrote:
> On Mon, Aug 10, 2015 at 11:35:41AM -0700, Durham Goode wrote:
>> # HG changeset patch
>> # User Durham Goode <durham at fb.com>
>> # Date 1422386787 28800
>> #      Tue Jan 27 11:26:27 2015 -0800
>> # Branch stable
>> # Node ID 6ef23dd36dfd7ccd467b55f0ad59ccbe07e4b08c
>> # Parent  79f0cb97d7537a7c2948f8f9b0a89148825a3a1d
>> copy: add flag for disabling copy tracing
> In general I'm okay with this as an experimental flag, but I've got a
> laundry list of questions that I think are all easily handled with an
> updated commit message and maybe one extra round of benchmarks...
>
>> Copy tracing can be up to 80% of rebase time when rebasing stacks
>> of commits in large repos (hundreds of thousands of files).
> Has anyone put any effort into fixing copy tracing? I'm assuming
> there's some potential smarts that could be done by walking the
> filelogs for the files in the rebase and looking at only those
> changes? Or am I missing something (again, I think, as I seem to
> remember chatting about this at a sprint) that might stand to be in
> this commit message for future archaeologists?
The problem is that copy tracing is fundamentally an O(number of files 
in the repo) operation.  In order to know if file X in the rebase source 
was copied anywhere, we have to walk the filelog for every new file that 
exists in the rebase destination (i.e. a file in the destination that is 
not in the common ancestor).  Without an index that lets us trace 
forward (i.e. from file Y in the common ancestor forward to the rebase 
destination), it will never be an O(number of changes in my branch) 
operation.

I'll add this to the commit message and resend.
>
>> This provides the option of turning off the majority of copy tracing. It
>> does not turn off _forwardcopies() since that is used to carry copy
>> information inside a commit across a rebase.
> *nod* One thought: could this be the default behavior when all edited
> files exist in both the original and new base for the rebase? That
> seems like it would fix the obvious move cases and still provide most
> of the win?
That won't catch situations where the file has been copied elsewhere. So 
the original still exists, and the modification wants to be applied to 
the original and the copy at the destination.
>
>> This will affect the situation where a user edits a file, then rebases on top of
>> commits that have moved that file. The move will not be detected and the user
>> will have to manually resolve the issue (possibly by redoing the rebase with
>> this flag off).
>>
>> This takes rebasing a 3 commit stack that's a couple weeks old from 65s to 12s.
> On what repository? What kind of scale? How about a 3-patch stack
> that's a few thousand changes back on mozilla-central as a benchmark
> that's more generally useful?
 From a repo with hundreds of thousands of files, and across >10,000 
commits.  I'll add a benchmark against mozilla-central to the commit 
message and resend.