[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