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

To answer part of your question: The Locate Change sets editor can help you identify which work items 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', and whether or not there is an 'equivalent' change set in the flow target of the Pending Changes view (for the cases when an 'original' is incoming and the 'backport' is outgoing or vice versa).
Both features are explained in detail in the "Improved Gap Handling for SCM" article: https://jazz.net/library/article/1372

The fix is work item 128329, but although it is high priority, it
unfortunately doesn't look like it will make it into the next release
(although it is already high priority, it wouldn't hurt to add a comment
to that work item indicating your interest).

Unfortunately, I don't have a good workaround ... one thing that can
help a little bit is to add a comment to the description of the stream,
indicating the last date when you inspected the stream for incoming
changes. That way, the next time you look, you know to ignore any
incoming changes before that date. And of course, update that date each
time you have done a scan for any changes.

Cheers,
Geoff

On 11/14/2011 8:53 AM, ulricheckhardt wrote:

Hi!

I'm currently trying to merge some changes from our main development
stream to a branch that was made a good half year ago. Due to
conflicts, I can not accept changes into the branch; I have to use
patches instead. Some of the changes were already merged to fix other
bugs, too. Now, when filtering through the list of incoming change
sets, I need to pick those that are necessary for the fixes but were
not yet merged. The problem there is that when accepting a changeset
as a patch, the changeset is still marked as incoming, so not only do
I have to manually find those that need to be included, but I have to
manually exclude those that were already incorporated - a
labour-intensive task due to the sheer amount of changes made in the
last months.

Does anyone have a suggestion how I can make this task easier? How do
you deal with such tasks?

Thank you!

Uli