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:32 EDT