Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Andreas Krey wrote: > Now, since the revisions A2 and A3 are already present in B, > we can not base the merge on revision A1. Instead we need to > look into the graph finding the closest common revision, which > is A3. We have change lines A3->B2-B3 and A3->A4, meaning that > we need to do diff3 with A3 as base and A4 and B3 als leaves. In that case you'd lose the changes in B1.... you need that change as well, and since the other merges are potentially dependent on it you need to start there at a minimum. The mergepoint doesn't help here. You could optimise the case where there were no manual changes at all to the branch (in theory, don't know how easy that would be in practice, since you don't actually know that information at commit time.. perhaps some kind of diff with the source to determine exact equivalence) but the moment any change is made that is not the result of a simple merge then that's the earliest point you can take a merge from. > Also notice that we could regard the first merge as changing > the branch structure so that B is now effectively rooted in > A3 instead of A1 for determining all further merge operations. > After a merge the 'merged-over' part of the graph becomes > irrelevant for that. If you're merging into A you always use the tip of A as the merge target. What matters is the source branch. Mergepoints allow you do reduce complexity by ignoring parts of the source branch (since they have been already merged). Tony