[PLUGIN] Alternative merge pulls history, and finds best base.

[Martin Pool]

On  4 Jul 2005, John A Meinel <john at arbash-meinel.com> wrote:

> >I think that a much better approach is per-file graph searches - for
> >each file that has a different last-modifying revision between the two
> >trees, decide on a base using a similar algorithm. This will give much
> >better results because two files that may provide mutually exclusive
> >'best' results can both be satisfied.
> >
> Doesn't that tend to get really expensive for large trees? I mean, if I
> have a large tree, and I'm slowly improving it, that means that
> potentially you would start a search for each.

Each file?  Yes, in the simplest form.  So the best thing might be to
store a subsection of the graph for each file along with the history
for each file, so the amount to consider is related only to the
complexity of the history of that file.

> I can see how you could have two fairly long-lived branches, which
> happen to both merge a short-term branch, and then when they try to
> merge eachother they would pick the short-term branch, rather than the
> original split.
> 
> With bzr there is a slight difference between the main development line
> (revision-history) and merges. I was thinking about looking for common
> entries along there, since that indicates a more 'primary' role of the
> revisions.

I think a slight bias in favour of the mainline is proably a good
idea.

-- 
Martin