Resuming change sets - respect order?
![]()
Gabriel Valencia (11●3●4)
| asked Nov 18 '10, 9:06 p.m.
retagged Jun 24 '14, 11:44 a.m. by David Lafreniere (4.8k●7)
I just found that if I suspend a large group of change sets and then resume them, I get dialog saying there is a gap and I need to either accept more change sets or apply as a patch. However, I've selected literally all the change sets and I don't want to do this as a patch. So I have to resume the change sets one by one by the date of the change set.
So I tried associating all the change sets to a WI one by one as I resumed them, expecting the order to apply in the next suspend/resume. However, turns out it didn't! RTC still complains about the gap. And I have to once again resume them one by one as before. Is this expected behavior? Why wouldn't RTC resume according to the date at least? Is there something else I can do to be able to quickly suspend/resume a large group of change sets without having to go through them one by one? It really costs me significant time, which I think defeats the purpose of suspend/resume. |
3 answers
![]()
Sorry, forgot to mention I'm on RTC 2.0.0.2 iFix 4.
|
![]()
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 19 '10, 1:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I've run into this myself periodically (and recently).
I've submitted this as defect 140346. Cheers, Geoff On 11/18/2010 9:08 PM, gvalenc wrote: I just found that if I suspend a large group of change sets and then |
![]()
The issue that you identified where sometimes resuming change sets would report a gap when there was none was fixed in RTC 3.0.1 in When resuming a set of change-sets, it appears to try to resume them in the wrong order, and reports a "gap" (140346).
If you are trying to resume change sets that really do have a gap, the following information might be useful: 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 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 |
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.