[PATCH 3 of 3] graft: apply get-only changes in-memory

Matt Mackall mpm at selenic.com
Mon Nov 19 15:46:11 CST 2012


On Mon, 2012-11-19 at 12:01 -0800, David Schleimer wrote:
> # HG changeset patch
> # User David Schleimer <dschleimer at fb.com>
> # Date 1353354272 28800
> # Node ID d4f1efa15442572e7ea658b50a02e093492797d7
> # Parent  a77f8405c800c27ba5cb97b7482410c6438c81c8
> graft: apply get-only changes in-memory
> 
> This changes the graft code to apply the simplest-possible changes
> in-memory.  Specifically, changes where all we need to do is set the
> contents of files to the version in the commit being grafted.  This
> means that no files were deleted and no files were modified on by both
> the target branch and the change we're grafting.
> 
> Based on one of our real-world branches, with 497 grafts,
> approximately 80% of cherry-picked commits will fall into the fast
> case here.  This patch takes a graft with all 497 revisions on the
> branch in question from 5250 seconds to 3251 seconds.
> 
> The revisions that fall in the fast case were more common near the
> beginning of the branch than the end.  Longer lived branches are
> likely to see less of an improvement from this patch, but they should
> be unlikely to see a regression.
> 
> +                supportedactions = set(['g'])

Eek. Obscure internal details escaping from merge.py = not good.

In just about all of Mercurial's own usage of graft, this approach will
make things slower because grafts almost always involve at least one
(automatic) file-level merge. I suspect Facebook is exceptional here.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list