I didn't see the original mail so I don't know the details of the problem /
solution. I'll also be offline for a few days but let me provide some
general information.
The selected base contributor (common ancestor - CA) plays a critical role
in the outcome of a merge and merge arrows play a critical role in selection
of the CA. If you go around manually drawing merge arrows you can mess up
merge / findmerge.
The essence of merging is to propagate all of the changes between the
from-version and the CA to the to-version. The presence of a merge arrow
asserts that this propagation has occurred.
Have you ever noticed that a selective merge (additive or subtractive)
doesn't draw a merge arrow? That's because these merges don't meet the
semantics implied by a merge arrow. Similarly, if you specify the "-base"
option to "ct merge" an arrow isn't drawn because the -base version isn't
trusted as being the "right" CA.
As for the merge algorithm, at a high level, it goes like this:
- pick a CA.
This is done strictly analyzing the topology of the vtree *including* merge
arrows. No version data is analyzed. In general, it's a non-trivial
algorithm.
- determine if a merge is needed.
A merge is needed if and only if the version data of the "from-version"
differs from the version data of the CA. If they're identical, there simply
are no changes to propagate.
- If a merge is needed then it is either:
(a) an arrow-only merge: the to-version and the from-version's data is
identical; just draw a merge arrow
(b) a trivial merge: the to-version has identical data to the CA so the only
changes are those present in the from-version; it is simply copied to the
to-version or
(c) a "real" merge: relative to the CA, there are changes in both the "to"
and "from" version. Each contributor's version data is independently
compared to the CA's version data. Changes from one that don't conflict
(overlap) with the other are simply applied to the CA's data; conflicting
changes require user intervention to indicate the "correct" result.
I think that sums it up.
Dale LaBossiere labo@rational.com
Rational Software
----- Original Message -----
From: EXTERN Yeats Darren (WA Consultants; K5/ESQ1)
<Darren.Yeats@de.bosch.com>
To: 'Christian Goetze' <cg@digisle.net>; <cciug@Rational.Com>
Sent: Thursday, January 20, 2000 11:15 AM
Subject: RE: [cciug] Bidirectional merge arrows anyone?
>
> This is an interesting idea, Christian.
>
> I tried out some examples on paper. Indeed, it seems that by using a
> bi-directional merge arrow after a copy-merge you can get a base
contributor
> nearer to the other contributors, as compared to using a uni-directional
> merge arrow. This could in turn make a difference to the merge result. So
I
> think I agree with you on that point.
>
> Whether this different result is always a valid one is another matter,
> though... I think sometimes it isn't. I can send along my "paper" example
if
> you want. But before getting into that--after all my example may contain
an
> error--does someone else already know if this works or not, with an
> explanation?
>
> I guess I'm asking the Rational people, since they designed the merge
> algorithm. They might aswell pipe in now.
>
> --
> Darren@Yeats.co.uk +44-7958-679115
> Software Configuration Management
> --
> darren.yeats@bosch.com +49-711-81132213
> Robert Bosch GmbH
>
> > -----Original Message-----
> > From: Christian Goetze [SMTP:cg@digisle.net
> > Sent: Wednesday, January 19, 2000 8:36 PM
> > To: cciug@Rational.Com
> > Subject: [cciug] Bidirectional merge arrows anyone?
> >
> >
> > In my process, I know that certain kinds of merges will always be copy
> > merges. I am wondering if I should "document" this fact my adding a
merge
> > arrow in the other direction for this case. I expect this to make
> > findmerge's life easier by providing the additional insider info,
allowing
> > findmerge to find a better base contributor or something. It also has
the
> > advantage of bypassing a little problem cuased by the RCS keywords
checkin
> > triggers which causes the copied files to not be identical, only
logically
> > equivalent.
> >
> > Has anyone experimented with bi-directional merge arrows?
> > --
> > cg
> >
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> >
> >
> > http://clearcase.rational.com/cciug/mailing_list.html
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:22:33 EDT