Changeset dependency via RTC Client API
its been a while we are having change set processing for the build. The validation runs with some work item state validation. the scenario where dependency issue comes. we have sorted out the item id associated with change and the timing of the change set. But some time deletion and addition is not that much accurate as item ids may get changes in that scenario.
Is there direct way to get list of all dependent change sets of deliver the independent change sets and ignore the one dependent to any other change set yet not ready.
Thanks in Advance.
Praveen.
2 answers
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:
client side: IWorkspaceConnection.findChangeSetsToAcceptToFillGap(...)
server side: IScmQueryService.findChangeSetsToAcceptToFillGap(...)
There is an article which talks about gaps here: https://jazz.net/library/article/1372
Comments
Hello Thanks for update,
but this solution is not seems good for massives builds across 200 Developrs. Because we as DevOps will be in trap what is missed and what is com\ing now. At least in current world there is flow that we can maitain and track.
Let me know if there is any direct API to say changeSet.getDependencyList and it will return all the depedent change sets.
I saw the dependents are getting highlighted while we selects the change sets in the UI. I want to get that API references.
I've converted your answer to a comment under David's answer. I assume you are responding to his solution. In the future, please reply to an answer instead of creating a new one when you are commenting on it. This helps others follow the conversation thread.
1 vote
Unfortunately RTC 5.0 is needed to determine the complete list of change sets to accept that would fill a gap. There is no API available at all prior to 5.0 that could calculate this.
The classes (in 5.0) that are involved for filling the gap include:
client side: IWorkspaceConnection.findChangeSetsToAcceptToFillGap(...)
server side: IScmQueryService.findChangeSetsToAcceptToFillGap(...)
but this solution is not seems good for massives builds across 200 Developrs. Because we as DevOps will be in trap what is missed and what is com\ing now. At least in current world there is flow that we can maitain and track.If you identify specific use cases that fail related to this, feel free to explain them in detail, as there may be other workarounds available.
Hello David,
I think this may touch the chord, only one thing missing.
Lets say In Dev Stream 1,2,3,4,5,6 versions are available for an file. In promoted Stream Only 1,2,3 ... Now by my utility if user choose version 6 as ready by marking task as done. I use provide report that the change set is dependenct to 5 and its task id...
the case above seems fine if I anyhow accepts the change 6 and then later on I call the API above to accept 5 to fill the gap.
So missing part is how can I accept 6 ignoring the gap. If that is possible then I can work that out to get the 6 first ignoring the gap and later on accept 5.....
So pseudo code will be...
Collect outgoingApproved Changesets
Deliver or accept the change set to fill the gap. (to fill earlier build missing change sets)
Deliver all ignoring the gap. (this I want to know how to achieve.)
"So missing part is how can I accept 6 ignoring the gap"
Accepting a change set but ignoring the gap can be done in the RTC 4.0.5 client, but it is a manual process since merging is required (there is no way to automate this process). This manual process is explained in https://jazz.net/library/article/1372 and shown in the following videos:
http://www.youtube.com/watch?v=28raag5RdzU&feature=youtu.be
http://www.youtube.com/watch?v=TucVu_BgB7E&feature=youtu.be
Since the before state of the change set you are trying to accept does not exist in the history of the repository workspace you are accepting into, different types of conflicts can occur, requiring manual merging. The file content could be completely different in the accepted change set (source) versus the content that is already in the workspace, and there may be no way to automatically merge in the changes from the source change set. Other structural conflicts could have occured due to deleting/renaming/moving the file in the gap (i.e. in the change sets not being accepted), which would also require manual intervention to resolve.