cross stream merges: flagging "patched" change set
hi,
this is another post about limiting the "noise" caused by the accumulation of change sets that we do not want to accept when merging streams.
I am aware that there are a few enhancement requests on the subject (102223, 2195, ... ) but i am also aware of the low probability of those requests to be acted upon :-)
So i was wondering if a different spin to a somewhat narrower use case would be possible.
For various reasons, lack of cross component support being one of them, gap exceptions occur when merging change sets from one stream to another, when it occurs the tool turns to the patching mechanism. That's a fact of life and that's fine.
The problem however is that patched change sets never "go away" and tend to accumulate (quite dramatically in my team's case).
I understand that the RTC model doesn't tolerate gaps in history when accepting changes and simply "hiding" incoming changes would ultimately cause just that. But why not flagging change sets that have been brought in via the the patch mechanism?
Such flagged change sets would not actually be part of the history of the stream (the patch content being delivered via its own change set anyway) but would allow some filtering on views like the "pending changes" and therefore reduce the noise of irrelevant change sets during cross stream merging operations.
In this context, filtering "patched" change sets would not bring gaps exception upon us since the very reason of the patch was a gap exception in the 1st place.
Now... pushing the idea a bit further... why not allow users to manually flag changes sets as patched? It could work like the "ignore" flag we can apply on resources and would need to be delivered as a change set like any other.
Safe guards could be put in place to prevent delivering "patched" flags on change sets that are already part of the history of the stream the workspace flows to.
The existing workflow rules that forces you to accept any "incoming" changes conflicting with your "outgoing" changes prior delivery would still apply and should prevent any abuse of the feature.
regards,
d.
this is another post about limiting the "noise" caused by the accumulation of change sets that we do not want to accept when merging streams.
I am aware that there are a few enhancement requests on the subject (102223, 2195, ... ) but i am also aware of the low probability of those requests to be acted upon :-)
So i was wondering if a different spin to a somewhat narrower use case would be possible.
For various reasons, lack of cross component support being one of them, gap exceptions occur when merging change sets from one stream to another, when it occurs the tool turns to the patching mechanism. That's a fact of life and that's fine.
The problem however is that patched change sets never "go away" and tend to accumulate (quite dramatically in my team's case).
I understand that the RTC model doesn't tolerate gaps in history when accepting changes and simply "hiding" incoming changes would ultimately cause just that. But why not flagging change sets that have been brought in via the the patch mechanism?
Such flagged change sets would not actually be part of the history of the stream (the patch content being delivered via its own change set anyway) but would allow some filtering on views like the "pending changes" and therefore reduce the noise of irrelevant change sets during cross stream merging operations.
In this context, filtering "patched" change sets would not bring gaps exception upon us since the very reason of the patch was a gap exception in the 1st place.
Now... pushing the idea a bit further... why not allow users to manually flag changes sets as patched? It could work like the "ignore" flag we can apply on resources and would need to be delivered as a change set like any other.
Safe guards could be put in place to prevent delivering "patched" flags on change sets that are already part of the history of the stream the workspace flows to.
The existing workflow rules that forces you to accept any "incoming" changes conflicting with your "outgoing" changes prior delivery would still apply and should prevent any abuse of the feature.
regards,
d.
One answer
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
The Locate Change sets editor can help you identify which change sets have already been backported or not. We also add icon overlays/decorators on the change sets to help identify whether it is an 'original' change set, or a 'backport'. We also added both an icon and textual overlay/decorator on a change set node for the 'rare' cases when there is an 'equivalent' change set in the flow target of the Pending Changes view (ex: when an 'original' is incoming and the 'backport' is outgoing or vice versa). We did not add support in for completely hiding these 'equivalent' change sets from the incoming/outgoing folders. At least this functionality is a huge step forward in terms of what you are asking for vs what is available in the old patching mechanism.
Also, 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
Both features are explained in detail in the "Improved Gap Handling for SCM" article: https://jazz.net/library/article/1372
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
The Locate Change sets editor can help you identify which change sets have already been backported or not. We also add icon overlays/decorators on the change sets to help identify whether it is an 'original' change set, or a 'backport'. We also added both an icon and textual overlay/decorator on a change set node for the 'rare' cases when there is an 'equivalent' change set in the flow target of the Pending Changes view (ex: when an 'original' is incoming and the 'backport' is outgoing or vice versa). We did not add support in for completely hiding these 'equivalent' change sets from the incoming/outgoing folders. At least this functionality is a huge step forward in terms of what you are asking for vs what is available in the old patching mechanism.
Also, 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
Both features are explained in detail in the "Improved Gap Handling for SCM" article: https://jazz.net/library/article/1372