I can clearly see what change sets have been delivered to any specific stream, but we often want to validate that a specific change set has been delivered to a bunch of streams.

The only way I can think of doing that is to search the history of each stream for the change set.

Is there a better way to figure out what streams a change set has been delivered to?

https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/93619

There is a story requesting this feature.

Currently, there is only a way to find out for one stream. You can right-click on a change set and locate it. It allows you to select a stream/workspace and it will search the history for you. You would have to do this for each stream that you wanted to search.

If the change sets are from one work item, you can use the work item as a hint to which build the changes were introduced. If attached build result A is built from changes in stream 1 then you can determine that changes from the work item were delivered to the stream just before that build.

It's not perfect so I would suggest adding your support to story 93619.

That's pretty close. But like many stories there it is big, and I would be only interested in traceability from a change set to what streams contain it. Simple eh? Can't believe it isn't supported...

https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/93619

There is a story requesting this feature.

Currently, there is only a way to find out for one stream. You can right-click on a change set and locate it. It allows you to select a stream/workspace and it will search the history for you. You would have to do this for each stream that you wanted to search.

If the change sets are from one work item, you can use the work item as a hint to which build the changes were introduced. If attached build result A is built from changes in stream 1 then you can determine that changes from the work item were delivered to the stream just before that build.

It's not perfect so I would suggest adding your support to story 93619.

It's not quite so simple now that changes can flow to other servers. There may not be indicators present to determine which servers to check for the changes or if the user even has the credentials to access the server.

I believe the story is trying to cover which streams have a given change set. It may involve quite a lengthy query. If you've tried to locate a single change set in one stream, it doesn't always return a result instantly. Expanding that to search multiple streams may fulfill your requirement but it wouldn't be quick to use.

That's exactly what I mean by it is bigger than what I need.

Agile baby, implement the simple case first. You can always extend it with broader functionality later...

It's not quite so simple now that changes can flow to other servers. There may not be indicators present to determine which servers to check for the changes or if the user even has the credentials to access the server.

I believe the story is trying to cover which streams have a given change set. It may involve quite a lengthy query. If you've tried to locate a single change set in one stream, it doesn't always return a result instantly. Expanding that to search multiple streams may fulfill your requirement but it wouldn't be quick to use.

I believe the simple case of searching in a set of streams is not so simple. It would be a long running query since it already takes some time to run on one stream. Running a query like that for multiple streams wouldn't provide acceptable performance.

It's not just that it's complicated. It's also that it wouldn't be fast. It wouldn't be any better than using locate change set on each stream the user wanted to check.

What you could do is let the user pick what streams to search. That would, by default be easier that have to manually search each.

I believe the simple case of searching in a set of streams is not so simple. It would be a long running query since it already takes some time to run on one stream. Running a query like that for multiple streams wouldn't provide acceptable performance.

It's not just that it's complicated. It's also that it wouldn't be fast. It wouldn't be any better than using locate change set on each stream the user wanted to check.

I know this topic is really old, but I'd like to point out that a "Locate Change Sets" editor was added back in RTC 4.0 which supports this request.

See the following video on how it works: https://www.youtube.com/watch?v=iyX32R7da2c

---

Here's a summary on how to use the Locate Change Sets editor:

Use the Locate Change Sets editor to determine which streams, repository workspaces, snapshots, or baselines contain a change set or set of change sets. (Note: The ability to search in baselines was added in RTC 4.0.6)

In the "Change Sets" area, you can search for one or more parent or child work items or change sets. You can also drag one or more change sets, work items, or work item queries into the "Change Sets" area from other views or editors, such as the Pending Changes view.

In the "Search Targets" area, you can search in one or more streams, repository workspaces, snapshots, or baselines. You can drag the following items into the Search Targets area:
  - One or more streams, repository workspaces, snapshots, or baselines from other views, such as the Pending Changes, Search, or History views.
  - One or more team or project areas, which adds all streams owned by those team or projects areas.
  - A repository connection from the Team Artifacts view, which adds all streams in the repository.
  - One or more build results from the Builds view, which adds all corresponding build snapshots (if they exist).

Change sets that are listed in the search targets are included directly. Change sets that are linked to a change set in the search target are indicated as being included indirectly.