How do you find missing changesets if there is a gap in the timeline?
Accepted answer
There are high priority work items designed to help automate this.
One workaround is:
Open the change set that you cannot accept in the change explorer.
Select one of the files in the change set, and open that file in the "history" view.
Try to accept all of the change sets for that file.
If that still fails with gaps, find the earliest change-set in that history that you don't have in your workspace (you can use the "Locate Change Sets" operation to help with that). And start accepting that and its successor change sets until you hit a gap. Look at the change set with a gap, and start doing the same operation on another file in that other change set.
Comments
Thanks! Is there any chance you could you provide the relevant story/stories so I can track them?
A top level plan item is [CCM] improve scm merge handling - gaps (170001)
There are two alternatives to handling gaps: "filling the gaps" (what this question is about) and "backing out the gaps" (accepting a variant of the change set with the changes from the gap backed out). There is a lot of work currently targeted for the 4.0.3 release on backing out the gaps, but the work on the "filling the gap" alternative hasn't really started. The top level plan item for "filling the gap" is As a user, I would like to have the option of filling the gap when gaps are encountered (244998) .
The "Filling the Gap" feature "Story 244988: As a user, I would like to have the option of filling the gaps when gaps are encountered" is currently scheduled to be released in RTC 5.0
Here is a more complete summary of the gap work and relevant links:
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: https://jazz.net/downloads/rational-team-concert/releases/4.0.5?p=news#scm-improve-usability-405-m1
<continue reading my comment below>
Below are some videos which show this feature:
-Accepting multiple change sets with gaps in the RTC 4.0.5 client for Eclipse IDE: https://www.youtube.com/watch?v=28raag5RdzU
-Accepting a change set with a gap in the RTC 4.0.5 client for Eclipse IDE: https://www.youtube.com/watch?v=TucVu_BgB7E
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: https://jazz.net/downloads/rational-team-concert/releases/5.0?p=news#eclipse-fill-gaps
The classes that are involved for filling the gap include (available in RTC 5.0):
client side: IWorkspaceConnection.findChangeSetsToAcceptToFillGap(...)
server side: IScmQueryService.findChangeSetsToAcceptToFillGap(...)
Both features are explained in detail in the "Improved Gap Handling for SCM" article: https://jazz.net/library/article/1372