Thanks for the response. I think I have it worked out, and I'm pretty sure
that in my particular case, drawing a bi-directional merge arrow will
solve my problem.
Let me explain the situation. My process ensures that I have this picture:
(use fixed width font to view this)
integration branch ----O-------------O------------
\ /
\ / => time
\ /
\ /
development branch ---------O---O-----------------
The merge from the development branch into the integration branch is the
copy merge in question. Since my process garantees that I will never have
this:
...
\
integration branch ----O-----O-------O------------
\ /
\ / => time
\ /
\ /
development branch ---------O---O-----------------
I know that the "/" merge is a copy merge. The problem arises later, when
I want to check whether this merge is required:
integration branch ----O-------------X------------
\ / \
\ / \ => time
\ / \
\ / \
development branch ---------O---X---------?-------
Now if the versions marked X are truely identical, then the merge
algorithm will correctly tell me that no merge is required.
Enter RCS keywords. I installed the type manager solution that will modify
RCS keywords on checkout and checkin, and use the type manager to ignore
the RCS keywords when comparing and merging versions.
The type manager works fine, except that findmerge seems to not use the
type manager's diff method to determine whether the versions marked X
above are the same. It bypasses it, notices that the X's are not the same
(differing by the keyword only) and will trigger a merge. The merge now
uses the type manager's merge method and the result is a conflict-free
copy merge, but an unnecessary one.
This is why I had the idea of adding another merge arrow to fool findmerge
into avoiding this unecessary merge, resulting in this picture:
integration branch ----O-----------X------------
\ / \
\ | | => time
\ | |
\ \ /
development branch ---------O------X------------
Now findmerge will not be tempted since it will see the merge arrow and
assume the merge is already done. The question is whether this will affect
future merges.
I think it doesn't, as long as I can garantee that there is no version on
the integration branch between O and X.
Yeats Daren came up with an example where there is a version between O and
X, and where adding the merge arrow will lead to an incorrect merge
result.
I'd like to figure out a way to prove (mathematically) that I don't have a
problem as long as X is the direct successor of O on the integration
branch.
I actually think that the picture above is sufficiently important to merit
some additional thought. I think that the bidirectionl merge arrow in that
picture acts like a branch, and that the two X's are logically equivalent
when looking for ancestors. In other words one should be able to treat the
X on the development branch like a version zero and disregard its "real"
ancestors on the development branch.
In particular, one should be able to specify O on the integration branch
as a valid argument for a subtractive merge from X (or any successor of
X) on the development branch. This would very neatly implement the
semantics of an undo operation. Currently, to do the subtractive merge, I
actually have to remove the development branch...
Finally, it would be cool if the version tree browser would understand and
display bidirectional merge arrows like a kind of branch (my preference
would be via two thin parallel lines).
-- cgOn Thu, 20 Jan 2000, Dale LaBossiere wrote:
> 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 > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > > > > > > http://clearcase.rational.com/cciug/mailing_list.html > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > > http://clearcase.rational.com/cciug/mailing_list.html >
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:22:33 EDT