RTC: Resolving stream gaps?

Question

I have a file in RTC (call it foo.c) that I modified and checked into a changeset (CS1) along with some other changes. I then modified that file again and checked it into a different changeset (CS2) along with other changes.

I've now run into a case where I want to deliver CS2 to a stream, but RTC is giving me an error that delivering that would create a gap in the stream (because of the change in CS1). I don't want to deliver all of CS1 yet, because it contains some changes that shouldn't be in a build yet. The original change to foo.c in CS1 was a minor removal of a #include, and doesn't affect anything else.

Is there any way to resolve that gap?

I see some stuff in the RTC documentation about applying patches, but I don't understand where it's going with that.
Is there a way to split a changeset into multiple changesets, which would allow me just to deliver the one file?

Answer 1

Update since 2012 (and the original "workaround" of delivering everything and reverting what you don't want):

See this thread:

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.
This feature is summarized in the RTC 4.0.5 'New & Noteworthy' page.

Below are some videos which show this feature:

• Accepting multiple change sets with gaps in the RTC 4.0.5 client for Eclipse IDE
• Accepting a change set with a gap in the RTC 4.0.5 client for Eclipse IDE

That is the Locate Change Sets feature:

---

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:

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.

---

Original answer (2012)

Is there a way to split a changeset?

I don't think so, reading the changeset man page:

A file or folder in a component cannot be part of more than one active change set.
When a file or folder is included in an active change set, all changes to it become part of that change set whether or not the change set is current, and changes to that file or folder cannot be explicitly checked in to a new change set until the active change set that includes it is completed.

Having foo.c in CS1 and CS2 means CS1 has been "completed" (frozen, in essence), and it would be bad to try and split it.

The patch solution means:

• cancelling CS1
• adding the additional change to foo.c to CS2
• redoing CS1 changes

See "How do I remove a change set from a stream?"

Story 149483 is about enhancing that cumbersome workflow, and the gap detection is being enhanced (Enhancement 24822)

---

The OP timwoj concludes:

I ended up just delivering all of it, then reversing the one that I didn't want.

Answer 2

Problem: CS1 changes foo.c, CS2 further changes foo.c. You only want to deliver CS2, but RTC tells you that would introduce gaps.

Solution: Create a patch from CS2 and suspend both CS1 and CS2. Then apply the patch, merge it into your workspace and check-in the changes which will create yet another change set, CS3, identical to CS2 but with no dependency on CS1. You can now deliver CS3.

After delivering CS3, you can discard CS2 and resume CS1 which will require you to merge with CS3.

Then you should be in the state that CS1 builds on CS3 and you can choose whether or not to deliver CS1 in the future.