Find dependencies for a changeset
Hi!
I have a changeset that is marked as a merge. Interestingly, this merge affects only a single file, and even that file's diff is empty! Still, trying to discard this changeset is impossible, since it would "create a gap".
Anyhow, what I'm wondering is how I can get from a changeset to the changesets it depends on. The best I found was to annotate the affected (here: unaffected) files and then guess the changesets from the way the lines in the history fork and converge, but surely there is an easier way to do this, or?
Cheers and have a nice weekend!
Uli
I have a changeset that is marked as a merge. Interestingly, this merge affects only a single file, and even that file's diff is empty! Still, trying to discard this changeset is impossible, since it would "create a gap".
Anyhow, what I'm wondering is how I can get from a changeset to the changesets it depends on. The best I found was to annotate the affected (here: unaffected) files and then guess the changesets from the way the lines in the history fork and converge, but surely there is an easier way to do this, or?
Cheers and have a nice weekend!
Uli
2 answers
Hi!This sounds like you've hit the scenario described in comment 17 of this work item: 21814
I have a changeset that is marked as a merge. Interestingly, this merge affects only a single file, and even that file's diff is empty! Still, trying to discard this changeset is impossible, since it would "create a gap".
Anyhow, what I'm wondering is how I can get from a changeset to the changesets it depends on. The best I found was to annotate the affected (here: unaffected) files and then guess the changesets from the way the lines in the history fork and converge, but surely there is an easier way to do this, or?
Cheers and have a nice weekend!
Uli
If you want to see the dependencies, you can show history on the item. It's similar to annotate but is faster because doesn't highlight the lines for the file, which seems like information you don't need in this situation. Instead, it just shows the change sets in order in the History view.
Here's a summary of the gap related features:
(Also, please also read Tim's answer for an explanation on why that may be happening)
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
(Also, please also read Tim's answer for an explanation on why that may be happening)
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