Identify affect streams & components with with different change sets
Karthik Krishnan (889●9●123●165)
| asked May 17 '16, 12:20 p.m.
edited May 24 '16, 9:06 p.m. by David Lafreniere (4.8k●7)
Normally we recommend the users to do the following:
- Make change in one stream.
- Take the change to another stream via changing Flow Target.
But in reality people make same/similar change twice in 2 streams and end up fixing one and not another.
Streams (S1 & S2)
Components (C1 in both streams)
Changes happening to file (ex: foo.c) on both the components.
Use case / Problem: When a change is happening on the same component & same file on 2 steams, and at later point if the change is defective, the bug fix needs to happen in 2 places.
Let's say when I do a Locate change set from the context of S1 it will give me the changes from S1 and not S2 which is correct and logical because the change was done twice and not the same change is taken over.
Question: If this scenario happens how to identify all relevant streams.
One possibility we thought was the fact the we could link the change sets programmatically from different streams of same components so that it would show in Locate change sets as linked "indirectly".
Is this possible at all?
|
One answer
Shashikant Padur (4.3k●2●7)
| answered May 17 '16, 11:05 p.m.
JAZZ DEVELOPER edited May 17 '16, 11:06 p.m.
I don't believe you can link change sets programmatically as there are no api's exposed that support it.
What you could is to drag and drop a team area or a project area or the repository to the search target in Locate Changesets view. The search target will get populated with all the streams from the team area/project area/repository. |
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.
Comments
I think it would be worthwhile to educate the users how to do it properly.
I agree with Shashikant, that this is the way to find out the streams the broken change went into. After deciding which streams to fix, it would be possible to load them with a new repository workspace and accept the fix. It might be necessary to do some merge operation to do this on some streams.