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.
Tony Hoyle wrote: > A mergepoint is basically point where you say 'for this version Branch A > == Branch B', and this works both ways.. eg. if you merge a->b, commit, > then b->a, there won't be anything to merge. I may be dense in my head, but I don't get this. Maybe this is related to the fact that I never really understood what exactly a mergep oint is or does, besides a line in the revision history that tells me when a merge happened, and a little magic that tells the merge command where to re-start. (Is there any documentation about this?) Let's say I have branch A with changes, and branch B with changes (both from a common ancestor). I merge A into B, resolve any conflicts, and commit (to B). Now I have in branch B all changes from the common ancestor to the tip of both branches A and B, plus of course the conflict resolution changes that occurred during the merging process. And I have a merge point, pointing from the tip of branch A to the tip of branch B. But in branch A, I continue to have /only/ the changes that happened on branch A -- not the changes of branch B, not the conflict resolution changes applied during the merge. Therefore, on a subsequent merge from branch B into branch A there should be something to merge, shouldn't there? For me, merge points are not really /points/, they are /arrows/: they have a start point and an end point, and as such are not bi-directional. But then, as I said, I may not get it... Thanks, Gerhard