[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