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

Both features are explained in detail in the "Improved Gap Handling for SCM" article: https://jazz.net/library/article/1372

In your particular case, you likely would want to start with a repository workspace that matches the desired flow target, accept the change sets CS2 and CS3 (resulting in a gap), then perform the gap workflow to create new change sets and then deliver them to the desired flow target. i.e. the gap workflow only works when accepting, not when trying to deliver a change set with a gap.

You have encountered the need for either work item 20810 ("fill the
gap") or work item 102223 ("backout the gap").

The current (not very good :-) workarounds are:
- For "fill the gap", search through the version histories of the files
in the change sets that cannot be accepted, and find change sets that
would fill the gap
- For "backout the gap", use the "patch" mechanism to create patches for
the change sets you want to accept (you'll have to do this in a workspace).

Cheers,
Geoff

On 11/16/2011 4:08 AM, mayab wrote:

Hi,

I have a problem with partial delivering change sets from one stream
to another.
My scenario:
- i have workspace connected to stream1, I changed the 'Flow Target'
to stream 2
- in the 'Pending changes' view I have 3 change sets:
cs1 (file1, file2, ...)
cs2(file10, file11,...
cs3 (file1, file20, ...)
- my target is to deliver cs 2 and 3 (cs1 is feature that should be
copied to stream2)
- when I deliver cs2 - success
- when I deliver cs3 - "Delivering these changes
would introduce gaps in the stream. You are trying to deliver a
subset of the outgoing change sets but they need to be delivered
together because of dependencies between them."
error is presented (I have one file that is part of cs1 too)

The problem is after this error message is presented I didn't find a
way to fix the conflict and continue with the deliver.

Thanks