It's all about the answers!

Ask a question

How to clean up a stream with a long history of improper merges (parallel changes)

James Monschke (835) | asked May 02 '14, 10:10 p.m.
We are currently using the 4.0.3 eclipse client for RTC.

Our team recently migrated from Perforce to RTC (with little training) and I am new to these forums.  Any help is appreciated.

Our company has a long history going back several years (under Perforce and now RTC) of frequently making parallel changes on different branches/streams rather than making the change on one branch/stream and then merging to the other.  Under Perforce this did not necessarily block further proper merges (although it made them more messy / dangerous).  We are finding that this pattern of bad merges has created much more extensive problems in RTC where it unfeasible to do correct merges.

The history of bad merges is far too extensive to try and roll-back and fix at this point, but are current plan is to try and remediate by creating a new synch-point / baseline from which we can go forward with proper merges.  I.e. we want to get the streams as closely in synch as we can with manual changes and then create a patch/merge/? that will tell RTC to treat everything as merged and consistent at this point (accepting that we won't ever have a proper merge history before this point).

What are the steps for doing this (safely) within RTC?
Or does anybody have alternative suggestions for remediation?


James Monschke commented Jun 04 '14, 5:45 p.m.

To clarify, my title was slightly inaccurate.  It should be:
How to clean up multiple stream development with a long history of improper merges (parallel changes)

Accepted answer

permanent link
Geoffrey Clemm (30.1k33035) | answered May 03 '14, 2:09 a.m.
First note that the only way you can change the merge behavior is to "adjust"  the "common ancestor" that the merge algorithm will pick (assuming you don't want to change the content of either stream).   To force the common ancestor to be "nearer", one thing you can do is:
- Create a workspace on one stream, and load that workspace into a sandbox
- Save a copy of that sandbox (everything but the .jazz5 folder)
- Merge the other stream into the workspace (resolving all conflicts with "mine").
- Delete the contents of the sandbox except for the .jazz5 folder.
- Move/copy your saved copy of the sandbox back into the sandbox.
- Checkin and deliver the results to the first stream.

A few questions though:
In what sense were the merges "bad"?   Did the developer get confused, perform an incorrect merge, checkin the results, so that the "bad merge" had to be subsequently fixed?
Can you give an example of such a bad merge?  
And how was this hard to handle in RTC?   I did a quick test, and if I merge two files that have had the same changes made to them, the default RTC text merge tool does not consider those identical changes to be conflicts.
James Monschke selected this answer as the correct answer

James Monschke commented Jun 03 '14, 7:20 p.m.

essentially, the merges were bad in that there were no merges.  I.e. developers were mostly uninformed about the need for merges and were in the habit of making identical (or almost identical) cut and paste changes to the same files across multiple branches / streams.

This has been going on for many years here.  One developer with more experience than I have with RTC is trying to do "bulk" merges to clean up the merge history, but that is still very risky and I still suspect that we may have to fallback to just creating a new baseline like I described above.

In Perforce it just made subsequent attempts to do a merge "messy" and more risky, but in RTC it will block any subsequent attempts to deliver merges because of the other changes that have been submitted on the streams without merging. 

In our case we are merging between several streams and not just changes made in multiple workspaces on the same stream.

Thanks for your help.

Geoffrey Clemm commented Jun 04 '14, 10:52 p.m. | edited Jun 04 '14, 10:52 p.m.

If "bad merges" just means "created the same change manually in both files", then I don't see that there is a problem (i.e. there is nothing you need to clean up).  The RTC merge tool just ignores identical changes in both files, so the only content that will need to be merged is the content that actually differs.  In the extreme case, where the two files are actually the same because the exact same changes have been applied to both versions, then you can just say "auto-resolve" and RTC will mark those two versions as having been merged.

James Monschke commented Jul 24 '14, 5:52 p.m.

Unfortunately, the changes are not always identical and some changes were not necessarily carried over to all streams/branches. 

We have now implemented this basic strategy and are now trying to move forward and get everybody used to doing merges properly.

Thanks for your help :-)

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.