finding/resolving a gap

Note: Please also read Geoffrey's other two answers as he provides additional information/workarounds.

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 solved the gap problem by accepting a change-set with no changes
in it, then something strange is going on, and if you had time to do so,
creating a work item describing the situation would be useful to allow
the dev team to look into it. Also note that what you accept are
change-sets ... not work items (although change-sets are linked with
work items, and the summary string from the linked work-item appears as
a prefix for the change-set label in the GUI).

Cheers,
Geoff

On 10/12/2011 6:08 PM, melissawsd wrote:

We eventually got the work item to deliver - the hard way, trying
different combinations till one worked. The solution was to include
a totally unrealted work item (work item had NO source member is
common). appears it was linking unrelated work items together.
Fortunately it is OK to deliver both work items to the stream.

Thanks - I will check out the work item you mentioned.
Mel

gmclemmwrote:
There is a work item to have the system tell you what the missing
change
sets are (24822: "Confirm Content Accept" dialog should be
more specific
(offer to fill in gaps when a gap exception occurs)).
Please feel free to add a comment indicating your interest/support.

Until that is available, you need to investigate by hand.
Here are some thoughts:

The gap exists in at least one of the histories of the
files/directories that were modified by the change-set.
To make this process easier, in your workspace, suspend all of the
change sets after the one that you cannot deliver.

For each file in the change set, ask for its history in the context
of
the workspace. The change-set(s) immediately before the one you
want to
deliver are candidates for filling the gap.

Perhaps others on the forum have additional suggestions.

Cheers,
Geoff

On 10/10/2011 4:53 PM, melissawsd wrote:
We have a work item with a larege number of source members, and
several changes sets. When we try to deliver the changes it says
there is a gap, but we cannot figure out where. We tried
delivering
all changes sets, and the change sets individually and still get
the
same message.

We deliver to two streams (A and B) All changes delivered to
stream
A, but we get the error when attempting to deliver to stream B.

Does anyone know how to find the gap, or to ignore it so we can get
the changes delivered?

We eventually got the work item to deliver - the hard way, trying different combinations till one worked. The solution was to include a totally unrealted work item (work item had NO source member is common). appears it was linking unrelated work items together. Fortunately it is OK to deliver both work items to the stream.

Thanks - I will check out the work item you mentioned.
Mel

There is a work item to have the system tell you what the missing change
sets are (24822: "Confirm Content Accept" dialog should be more specific
(offer to fill in gaps when a gap exception occurs)).
Please feel free to add a comment indicating your interest/support.

Until that is available, you need to investigate by hand.
Here are some thoughts:

The gap exists in at least one of the histories of the
files/directories that were modified by the change-set.
To make this process easier, in your workspace, suspend all of the
change sets after the one that you cannot deliver.

For each file in the change set, ask for its history in the context of
the workspace. The change-set(s) immediately before the one you want to
deliver are candidates for filling the gap.

Perhaps others on the forum have additional suggestions.

Cheers,
Geoff

On 10/10/2011 4:53 PM, melissawsd wrote:

We have a work item with a larege number of source members, and
several changes sets. When we try to deliver the changes it says
there is a gap, but we cannot figure out where. We tried delivering
all changes sets, and the change sets individually and still get the
same message.

We deliver to two streams (A and B) All changes delivered to stream
A, but we get the error when attempting to deliver to stream B.

Does anyone know how to find the gap, or to ignore it so we can get
the changes delivered?

There is a work item to have the system tell you what the missing change
sets are (24822: "Confirm Content Accept" dialog should be more specific
(offer to fill in gaps when a gap exception occurs)).
Please feel free to add a comment indicating your interest/support.

Until that is available, you need to investigate by hand.
Here are some thoughts:

The gap exists in at least one of the histories of the
files/directories that were modified by the change-set.
To make this process easier, in your workspace, suspend all of the
change sets after the one that you cannot deliver.

For each file in the change set, ask for its history in the context of
the workspace. The change-set(s) immediately before the one you want to
deliver are candidates for filling the gap.

Perhaps others on the forum have additional suggestions.

Cheers,
Geoff

On 10/10/2011 4:53 PM, melissawsd wrote:

We have a work item with a larege number of source members, and
several changes sets. When we try to deliver the changes it says
there is a gap, but we cannot figure out where. We tried delivering
all changes sets, and the change sets individually and still get the
same message.

We deliver to two streams (A and B) All changes delivered to stream
A, but we get the error when attempting to deliver to stream B.

Does anyone know how to find the gap, or to ignore it so we can get
the changes delivered?