[PATCH 3 of 3] graft: apply get-only changes in-memory
David Schleimer
dschleimer at fb.com
Mon Nov 19 16:20:41 CST 2012
> > + supportedactions = set(['g'])
>
> Eek. Obscure internal details escaping from merge.py = not good.
Apologies. manifestmerge wasn't marked as private so I assumed it was part of the API for the merge module. I can move this logic into a canmemoryapply() function in merge.py and the actual merge logic into a memoryapply() function, both on the merge module.
>
> 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.
It's possible that Facebook is unique in how rare file-level merges are. I would expect the rough pattern to apply wherever there is a single branch for a given release. I don't actually have any numbers to argue either side, however.
I would be rather surprised if this slowed down grafts significantly. I think the only extra work we will be doing for the cases where we need a file-level merge is iterating over the list of actions to check whether it contains something other than a get. Yes, we will have to do the clean update first, but if and only if the immediately-previously grafted revision did not need any file-level merges. I think that this should be a net positive as long as you have at least 2 grafts in a row that do not require file-level merges.
That said, this discussion is meaningless without numbers, and I would be happy to benchmark. Can you point me at Mercurial's own usage of graft? I don't see any calls to graft() in the mercurial source.
If this is a non-trivial regression to other use cases, would you accept a --bypass flag that turned this behavior on, similar to the one you mentioned for import?
--David
More information about the Mercurial-devel
mailing list