dependencies between change sets
Steffen Kriese (38●19●21)
| asked Apr 24 '12, 5:50 a.m.
retagged Jun 24 '14, 9:48 a.m. by David Lafreniere (4.8k●7)
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 |
Accepted answer
David Lafreniere (4.8k●7)
| 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
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
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
@steffenkriese: hmm, that's a good question. Did you ever find an answer for this?
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.