How to clean up a stream with a long history of improper merges (parallel changes)
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?
Thanks
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?
Thanks
Accepted answer
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.
- 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.
Comments
Comments
James Monschke
Jun 04 '14, 5:45 p.m.