It's all about the answers!

Ask a question

dependencies between change sets


Steffen Kriese (381721) | asked Apr 24 '12, 5:50 a.m.
retagged Jun 24 '14, 9:48 a.m. by David Lafreniere (4.1k7)
Hello,

I have a number of change sets. Two of these change sets involve changes in the same file. When I try to deliver the newer change set the RTC eclipse client gives the following error message:

"Delivering these changes would introduce gaps in the stream. You are trying to deliver a subset of the outgoing changes sets but they need to be delivered together because of dependencies between them."

RTC is absolutely correct with this complain no doubt about it. What I miss is a hint which change set is missing.

How can I find the missing change set in the eclipse client?

How do I find the missing change set in the java api (I have the IChangeSet object of the newer change set)?

Mit freundlichen Gren / Kind regards

Steffen Kriese

Comments
Bo Chulindra commented Sep 26 '12, 8:03 p.m.
JAZZ DEVELOPER

@steffenkriese: hmm, that's a good question. Did you ever find an answer for this?


Steffen Kriese commented Sep 27 '12, 4:15 a.m.

 

my solution for this on the Java api level would be something like this:

 

get a list of all incoming change sets

get the changed files for the change sets

check if an older change set has at least one same file as the requested change set. if so accept the change set as well

 

I think this could work, but I was hoping RTC would provide a more intelligent way than comparing time stamps.

Accepted answer


permanent link
David Lafreniere (4.1k7) | answered Jun 24 '14, 9:45 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
edited Jun 24 '14, 10:09 a.m.
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(...)
Ralph Schoon selected this answer as the correct answer

One other answer



permanent link
Tim Mok (6.6k38) | answered Oct 01 '12, 2:19 p.m.
JAZZ DEVELOPER
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.

Your answer


Register or to post your answer.