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.
Am 03.12.2005 schrieb Tony Hoyle: > The problem is created by the fact that B2 has the wrong base. > > If you're promoting HEAD->B1->B2 then B2 should be based on B1 (or > possibly the same revision of HEAD). By creating B2 out of a different > revision there is no possible way of retionalising it without an > existing mergepoint. > > You've got the situation: > > 1.3 -> B1 + changes (eg. 1.3.2.5) > 1.8 -> B2 + changes (eg 1.8.2.21) But revision 1.8 contain all merged changes from branch B1. From a logical point of view is there no difference when merging B1 -> HEAD or B1 -> B2, if B2 was split from revision "1.8" or later. In B2 are always all merged changes from B1, right? > The 'common ancestor' of both branches is 1.3, so the only possible (and > logical) merge of B1->B2 is the entireity of B1 onto B2. Once a > mergepoint is there it fixes this as it knows where the first merge was. Sorry, I disagree. From the logical point of view is in revision "1.8" all changes from B1. I'm understand that this is hard to program but that's a technical problem, not a logical. Please excuse my poor english, it's very hard for me. bye Detlef