In RTC, there is no such things as a change set being "for a stream" ... any change set can be accepted into any stream (although it may create conflicts or gaps when doing so). So a work item should only be linked to change-sets that logically combine to produce the change requested by the work item. If you have "variant" implementations of that work item (such as for different releases), then you should create a separate work item for each variant and associate the change-sets appropriate for a given variant only to that variant. You would use properties of the work item to identify which variant the work item implements.

Cheers,
Geoff

I have a requirement to pull in the changes for a workitem for a specific code stream. Using the API on ILinkManager, i am able to fetch all the changesets. There can be multiple changesets on the workitem, each feeding to back to different code streams. I wanted to filter changesets for a one such stream. Is there a standard way to implement this?

If by "change sets for a stream", you mean the change sets that have actually been delivered to a stream, then this is certainly something you can do (as you say, the Search command does this). Unfortunately, I'm not familiar with the actual code snippet you would need to write ... if you don't get a response in this forum, you probably should post to the jazz.extend forum, which is where most of the "coding" discussions take place.

Note: I misinterpreted your original question as being "what subset of the change sets of a given work item should be delivered to a stream" (i.e., a stream it hasn't been delivered to yet). In that case, you would want to change your current process and create a separate Task if you needed to create additional change sets in order to propagate to another stream, so that when propagating to another stream, you have the change sets for the different variants clearly separated. Even without this propagation issue, I'd recommend doing so in any case, because this lets you distinguish the work done originally fixing the bug, from the work done propagating it to new streams.

Cheers,
Geoff

Defects are tracked as single work items, whose changes, can be propagated (back porting/forward porting) to other release streams. In that case, the same workitem has multiple changesets, each for a different release.Within the Eclipse version of RTC tool, i see a Search Option(Menu->Search->Jazz Source Control->Change sets) for "Changesets" , where one can specify Component, Location(which can be either release stream or workspace) etc, in addition to other parameters. With this feature, i am thinking, there should some way in the API to figure out changesets for a release stream.

In RTC, there is no such things as a change set being "for a stream" ... any change set can be accepted into any stream (although it may create conflicts or gaps when doing so). So a work item should only be linked to change-sets that logically combine to produce the change requested by the work item. If you have "variant" implementations of that work item (such as for different releases), then you should create a separate work item for each variant and associate the change-sets appropriate for a given variant only to that variant. You would use properties of the work item to identify which variant the work item implements.

Cheers,
Geoff

I have a requirement to pull in the changes for a workitem for a specific code stream. Using the API on ILinkManager, i am able to fetch all the changesets. There can be multiple changesets on the workitem, each feeding to back to different code streams. I wanted to filter changesets for a one such stream. Is there a standard way to implement this?