dependencies between change sets

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 terms of Java, for filling the gap you can take a look at:
client side: IWorkspaceConnection.findChangeSetsToAcceptToFillGap(...)
server side: IScmQueryService.findChangeSetsToAcceptToFillGap(...)

There is no easy way to do this, which is why the Eclipse client doesn't do it for you. If you know the file that would have the gap, you can show the history of it and see the other change sets in history that are also outgoing. You'll have to deliver those as well.

My advice, it's tricky when delivering a subset of your outgoing changes so always get your repository workspace into a configuration where you deliver all outgoing change sets. The obvious problem is that you run into a problem of a gap and can't deliver. The other problem is you're not delivering all outgoing change sets. This may lead to compile errors in the stream when it looks fine in your sandbox. I recommend suspending changes that you don't want to deliver. It will reveal gaps (you won't be able to suspend the change set) and prevent simple mistakes of delivering changes that cause compile errors.