It's all about the answers!

Ask a question

Patching from another stream

Steve Briand (411817) | asked Aug 15 '12, 6:33 p.m.
retagged Jun 23 '14, 2:38 p.m. by David Lafreniere (4.8k7)
 Here is the scenario:
  1. We have a situation where there are a set of files in future release stream that need to be merged back to an older release. Both of these streams were imported from base ClearCase, but a new change set was created in the future release stream. 
  2. When either accepting the change set and then creating a patch or simply selecting one of the changes from the change explorer and creating a patch, the patch can be added to a workspace based on the older release stream. 
  3. In the pending changes view one can select "Merged into Workspace", "Resolve with Proposed" or "Remove from view" for the pending patch.
  4. For those files with conflicts, the following message is displayed.
Auto Resolve: None of these changes can be accepted. You will have to merge them manually. The text in brackets should explain why the change could not be accepted. 

There is no option to select the Compare Editor and the patch is not moved into the Unresolved section where one can invoke the Compare Editor. The Pending Patch remains with the same options available as described above. The conflicts are relatively straightforward and could be resolved using the Compare Editor.

What gives?

Steve Briand commented Aug 15 '12, 6:35 p.m.

I neglected step 3.4 with should have indicated that I selected "Merged into Workspace" from the context menu of the pending patch.

2 answers

permanent link
Geoffrey Clemm (30.1k33035) | answered Aug 17 '12, 7:27 a.m.
edited Aug 17 '12, 7:28 a.m.
The patch system has issues, which should be addressed by the high priority work item 128329, scheduled for RTC-5.0.   But until that is available, you will need to use the patch system.  I'm not an RTC patch expert, but in my experience, patches work best when they are generated in an RTC "accept" context.  In particular:
- load a workspace which contains the configuration that you want to patch
- open the work item that contains the change set that you want to apply to this configuration
- in the links tab of the work item, right click on the change set you want and select the "accept" operation
- if you are lucky, the accept will just work, and you are done ... but if not, it will tell you there is a gap, and do you want to create a "patch".   Say "yes", and the rest of the patch workflow should then work.

permanent link
David Lafreniere (4.8k7) | answered Jun 23 '14, 2:38 p.m.
In RTC 4.0.5 we delivered additional support when trying to accept change sets which have a gap (often encountered when trying to backport fixes). In a very brief summary of the feature, when you accept change sets with a gap, you can now follow a gap workflow that accepts one change set at a time and, for change sets that contain gaps, creates a new change set (with aided traceability), that contains the equivalent changes. This means users will not have to accept the change sets 'as a patch. Applying change sets as a patch has limitations compared to the new workflow (as discussed in the article below).
This feature is summarized in the RTC 4.0.5 'New & Noteworthy' page:
Below are some videos which show this feature:
-Accepting multiple change sets with gaps in the RTC 4.0.5 client for Eclipse IDE:
-Accepting a change set with a gap in the RTC 4.0.5 client for Eclipse IDE:

In RTC 5.0 we added a "fill the gap" feature where the change sets that fill the gap are shown to the user, allowing them to either accept all the change sets or to continue with the gap workflow that was available in RTC 4.0.5.
This feature is summarized in the RTC 5.0 'New & Noteworthy' page:

Both features are explained in detail in the "Improved Gap Handling for SCM" article:

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.