IScmService.deliverCombined gap problem
Ernest Crvich (192●1●21●19)
| asked Feb 17 '13, 7:44 p.m.
retagged Jun 24 '14, 5:04 p.m. by David Lafreniere (4.8k●7)
We seem to get gap errors sometimes when using deliverCombined() from our server plugin. We have a particular situation right now where we have three work items we're trying to deliver in one call to deliverCombined(), each of which links to one changeset each (all three altered the same file, and no other files are involved). Our program logic is thus:
1. obtain the IChangeSetHandles from the work item links and resolve each to an IChangeSet object 2. determine the timestamps of each using IChangeSet.getLastChangeDate(). 3. build an array of these IChange set objects in ascending order (oldest first), and give them to deliverCombined We know from a little TODO note in the javadocs that deliverCombined (unlike the client-side IWorkspaceConnection.deliver() method) isn't capable of figuring out what order to deliver changesets in, hence why we do #2 and #3: * TODO: deliverCombined currently depends upon the order that change sets are presented. * This restriction could be lifted if we were to be a bit more permissive w/gaps. We also have verified using the RTC UI that things are correct in the workspace and stream involved...i.e., that these three changesets are the only outgoing changesets that have modified the file in question. So there is definitely no "gap" involved outside of these three changesets. And we have verified that our logic generates all three IChangeSet objects in the array properly (in oldest-to-newest order). Must we call deliverCombined() with only one changeset at a time? Or is using IChangeSet.getLastChangeDate() not the proper method to use to determine delivery (and thus array) order? |
2 answers
|
Bah, never mind. For some reason the outgoing list in the UI wasn't showing an old outgoing set from November of last year that changed the same file (clicking on a file in the outgoing folder in Pending Changes usually highlights all other changesets that touched the same file, but it definitely wasn't doing so at first for us...that was our very first guess at what the problem was, but since there are several dozen outgoing changesets, we were relying on the highlighting to be sure that just our new 3 sets were indeed involved). After much head-scratching and trials and errors and refreshes, RTC finally started highlighting the older one properly (no idea why...we did not accept or deliver anything to either the workspace or stream), so now we know where the problem really lies.
|
David Lafreniere (4.8k●7)
| answered Jun 24 '14, 5:00 p.m.
FORUM MODERATOR / JAZZ DEVELOPER edited Jun 24 '14, 5:02 p.m.
Since your question is about gaps, here is is some information related to gaps that may be relevant to any readers of this forum question. In particular, the Java methods for the "fill the gap" feature delivered in 5.0 (and mentioned below) might be more related to this particular question (which could be used instead of trying to sort the change sets by their last modification date - which in essence does not guarantee the correct order).
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 |
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.