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.
Detlef Marschall wrote: > > There's a problem. The user must know that this is the first merge to B2 > for the specific source. Then he must use "-jTAG -jBRANCH" for the > merge, otherwise he can merge with "-jBRANCH". For only a few sources is > this OK. But there are 2816 sources, without includes, and nobody can > say how many he must change for a problem. Only when all sources was > merged from B1 to B2 then we can use mergepoints with no problem. 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) 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. The only revisions being considered during such a merge are 1.3->1.3.2.5 (common ancestor to branch head) being patched onto revision 1.8.2.21 (current sandbox revision). There are no mergepoints within that frame of reference. Once a mergepoint is registered at 1.3.2.5, any future merges will use that as their starting point. Tony