RTC Flow Targets & scope components
![]()
Nicolas GAY (11●1)
| asked Jun 16 '17, 11:50 a.m.
edited Jul 09 '17, 2:40 p.m. by David Lafreniere (4.8k●7) Hello,
There is a behavior I cannot explain Under RTC 6.0.2, about scope components in Repository workspace's flow targets. Maybe anybody can help? The issue is that I can deliver change sets of a component into a Stream which does not have the given component in the "scope components" of the target flow.
Here is the Scenario: - two streams: Stream1 & Stream2 - Stream1 contains component1 - Stream2 contains component1 and component2 - a Repository workspace is pointing to Stream1 as "incoming flow direction", "incoming current flow", , with "scopecomponents"=component1 only - the same repository workspace is pointing to Stream2 as "incoming,outgoing flow direction", "outgoing current flow", "outgoing default flow", with "scopecomponents"=component2 only
My goal is to be able to: - see any change on component1 delivered into Stream1, as an "incoming" change set of my Repository Workspace (and then to accept them) - be able to see as "outgoing" change set the changes made to "component2", and to have them be deliverable to Stream2 - be sure I WILL NEVER deliver any change set on component1 into Stream2
The issue I cannot explain: I can well see incoming changes on component1 and accept them. BUT then the same component1 appears as OUTGOING change of my repository workspace. In consequence I can deliver the last change set of component1 into Stream2!!
Actually, this does not make sense: component1 is not in the "Scope components" of the "Stream2" target flow. So why can I deliver change set on this component into Stream2? This is not what is described in the "Flow scope" section of https://jazz.net/help-dev/clm/index.jsp?topic=%2Fcom.ibm.team.scm.doc%2Ftopics%2Fc_csets_targets.html
Any explanation would be welcome to help me!
Thansk in advance to all.
Regards
Nicolas G |
Accepted answer
![]() Since component1 is not in the "Scope components" of the "Stream2" target flow, so changes in component should not get delivered into stream2. Ideally this kind of flow (component1 -> stream2) should not be shown in the pending changes view as component1 is not scoped for stream2. This issue was fixed in 6.0.3 release in the following WI: Defect 399540 David Lafreniere selected this answer as the correct answer
|
Comments
Hi Nicolas,
Could you please give us more details about, reason for using same Repository workspace for both streams ( stream1 and stream2)
I think you should be using a spereate stream.
Regards,
Arun.
Try using the separate repository workspaces for each stream