It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,884
×1,201
×889
×169
×23

question asked: Apr 27 '09, 10:28 p.m.
question was seen: 7,816 times
last updated: May 26 '16, 1:39 p.m.

Related questions

Determine, using API, if change set has been delivered

0
1
Ed Koezly (46●1●5●4) | asked Apr 27 '09, 10:28 p.m.
edited May 26 '16, 1:39 p.m. by David Lafreniere (4.8k●7)
Programmatically, using the RTC API, how can it be determined whether a change set has been delivered to a stream?

I'm looping through change sets using WorkspaceManager's findChangeSets method. However, it returns change sets that have been checked in as well as checked in and delivered.

For background, I'm trying to determine what delivered change sets are missing work items. I can find the work items by using the WorkspaceManager getChangeSetLinkSummary method. I'm guessing the change set itself doesn't "know" whether it's been delivered but that the stream does.

Accepted answer

0
permanent link
David Lafreniere (4.8k●7) | answered May 26 '16, 1:30 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
edited May 26 '16, 1:38 p.m.
This question sounds equivalent to the Locate Change Sets feature added in RTC 4.0.
All you would need to do for this is call <code>IWorkspaceManager.locateChangeSets(...)</code> (if you are on the client) or <code>IScmQueryService.findLocateChangeSets(...)</code> (if you are on the server)

Michael Valenta selected this answer as the correct answer

One other answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Christophe Cornu (471●2●3) | answered May 22 '09, 9:57 a.m.
Hi Ed:

For background, I'm trying to determine what delivered change sets are missing work items.

Given a stream S1 and a component C in that stream, you can browse through the change sets forming the history of that component C in S1.

See IChangeHistory IFlowNodeConnection.changeHistory(IComponentHandle)
Then IChangeHistory recent() previousHistory() getHistoryDescriptors() to navigate through the history and get the change sets.
Finally you can fetch the change set handles and inspect if the IChangetSet(s) have work items linked.
This is similar to how the History View is populated.

Maybe your situation is a little different than I assume from your original description. If you only care about change sets from a workspace W that may have been delivered to a stream S, then you can do things differently. You can compare the workspaces W and S and see if S has those change sets or not (similar to what the Pending Changes view does).

Use:
IChangeHistorySyncReport IFlowNodeConnection.compareTo with the flag WorkspaceComparisonFlags#CHANGE_SET_COMPARISON_ONLY since you don't care about baselines here. Then examine the report incomingChangeSets (or outgoing ChangeSets depending on the order of your comparison). If they contain the change set handles then they are not in the stream yet.

Let us know if you need more details.
In the future if we miss your question on the newsgroup you can force our attention by opening a work item against Source Control...

HTH,
Chrix
Comments
Stefano Antoniazzi commented May 26 '16, 11:30 a.m.

 Am I wrong or CHANGE_SET_COMPARISON_ONLY will miss all the Change Sets that actually are in a "not delivered baseline" but are really not present in the target?

Your answer

Register or to post 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.