Resuming change sets - respect order?
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.
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
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'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
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.
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
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