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

Please also read the 2 other comments from David Olsen and Geoffrey Clemm as they are also related to the question

If you are accepting all changes from MAIN into PB, then you should never get a "gap" conflict. I do remember there were some issues in earlier versions of RTC, where if you multi-selected a large number of change-sets, it sometimes accepted them out-of-order and reported a gap, when in fact there wasn't one. But if you click on "accept all" instead of multi-selecting, you should be able to avoid that behavior. Using the "replace in stream" method is another workaround, but that shouldn't be necessary if you are flowing all changes.

Cheers,
Geoff

Hi,

We have two stream one is called MAIN and another is called PB. Every month we accept all changes put in MAIN to PB and release a monthly PB. This time the monthly PB got bit late and we have quit a lot of change set to accept.

The problem is when we are trying to accepting changeset it says following;


"The repository workspace you are accepting this changeset into doesn't have all the change sets that led upto this change set. Yon can try applying the contents of the change set as a patch or you could try and accept more change sets together"

Now, message is self explanatory but how to find out which change sets are before this one? Also what is the level of change set RTC keep track of? I mean is it changes submited on stream level or a single Component within a stream?

NOTE: PB = Project Build

Could you please help us sorting out this problem because there are many change sets to accept and it will waiste so much time if we have to patch evry single one of them

Thanks

--

Sjunejo

On 5/9/12 7:53 , sjunejo wrote:

We have two stream one is called MAIN and another is called PB. Every
month we accept all changes put in MAIN to PB and release a monthly
PB. This time the monthly PB got bit late and we have quit a lot of
change set to accept.

The problem is when we are trying to accepting changeset it says
following;

"The repository workspace you are accepting this changeset into
doesn't have all the change sets that led upto this change set. Yon
can try applying the contents of the change set as a patch or you
could try and accept more change sets together"

Could you please help us sorting out this problem because there are
many change sets to accept and it will waiste so much time if we have
to patch evry single one of them

Depending on what you are trying to accomplish, you might be able to
avoid this problem all together.

Do changes happen in the PB stream independent of the Main stream? Or do
all changes in the PB stream come from the Main stream?

Do you always want to move everything from Main to PB? Or are there some
changes that you want to keep in Main but not migrate them to PB?

If no changes ever happen in the PB stream and if you want to move
everything from Main to PB (in other words if PB is a snapshot of what
was in Main at a particular point in time), then you want to replace the
contents of the PB stream rather than deliver individual change sets.
(I am not very familiar with replacing the contents of a stream, since I
don't do it very often. I think you use a repository workspace as a
go-between. You accept changes from Main into your repository workspace
so they have the same contents, then you change the flow target of the
workspace to be the PB stream, and then you do "Replace in ...")

If some changes happen directly in PB without going through Main, but
all changes from Main should go into PB, then you want to deliver the
changes from Main to PB all at once, not once change set at a time. The
procedure is similar to the paragraph above. You get a repository
workspace to be identical to the Main stream, change the flow target to
the PB stream, accept any changes from the PB stream, and then deliver
everything to the PB stream. You might have to do some merges if there
are conflicting changes in both streams, but you shouldn't run into the
problem of missing some intermediate change sets.

If you only want to deliver some of the changes from Main to PB, then
you have a problem. If one of the change sets that you want to deliver
depends on a change set that you don't want to deliver, there is not a
great solution. You could recreate the change in a new change set that
doesn't have a dependency on the unwanted change set. (The patch
mechanism will likely be helpful here.) Or you could go ahead and
deliver the unwanted change set but then create a new change set that
undoes the change. (The "Reverse" command may be helpful with this.)

(Change set A depends on change set B if the two change sets contain
changes to the same file on the same branch and if the version in change
set A is later than the version in change set B. Two change sets can't
depend on each other if they changed different files or if the files are
on separate branches.)

--
David Olsen | IBM Rational | Jazz Process Team