Source control: how does a stream hierarchy work?
![]()
I have looked at the documentation but can't find anything to explain the rules governing flow targets of a stream. Can anyone explain what it means when a stream has a flow target? I have searched for documentation about stream hierarchies but can't find any.
My colleague and I both work on the same component, but in different streams. We have both set the other person's stream as a flow target of our own stream. The component was originally created in my stream and was added to my colleague's stream. When I deliver changes to the component in my stream, they appear as incoming changes in my colleague's workspace. When my colleague delivers changes to the component in her stream, the changes do not appear as incoming changes for my workspace. Can anyone can explain what's going on here? |
8 answers
![]() I have looked at the documentation but can't find anything to explain the rules governing flow targets of a stream. Can anyone explain what it means when a stream has a flow target? I have searched for documentation about stream hierarchies but can't find any. Could you perhaps tell us what you are trying to achieve? It sounds like you want to have the same version of a component in both streams, and you both want to work on it at the same time. Also - if you are on 1.0.1 - create a Flow Diagram. This will show you exactly how you have things set up with components/streams/repo workspaces. and flows. Create a flow diagram by doing a right button on My Repository Workspaces->New->Flow diagram anthony |
![]()
smithwil wrote:
I have looked at the documentation but can't find anything to explain Nothing flows automatically between streams. Users flow change sets and baselines between streams using repository workspaces. Hope this helps, JohnC SCM Server |
![]()
We would like to add support for auto-deliver/accept at the stream level if no conflicts are detected, but for for now everything has to flow through a workspace. Given a flow hierarchy for two users as shown:
user1: W1 <-> S1 <-> S2 user2: W2 <-> S2 When user1 delivers to S1 (stream1), S2 isn't affected. To flow change sets to S2 he would from the Pending Changes view use the "Change Flow Target..." action and pick S2. The Pending Changes view will update to show the incoming/outgoing from W1 <-> S2. After user1 delivers from W1 to S2 then user2 will see those changes as well. Cheers, Jean-Michel |
![]()
Thanks for the replies. We're using RTC 1.0 so don't have the Flow Diagram feature yet, however I think Jean-Michel's diagram is correct:
user1: W1 <-> S1 <-> S2 user2: W2 <-> S2 Also, Anthony's interpretation "It sounds like you want to have the same version of a component in both streams, and you both want to work on it at the same time," is right. I think what confused me was that when I deliver changes to S1, they appeared as pending changes for my colleague's workspace W2. We assumed this was because S2 has S1 as a flow target. When my colleague delivered changes to the component in S2, they did not appear as pending changes in my workspace, even if I set S2 as a flow target of S1. In order to keep up to date with my colleague's changes I currently have to manually switch the current flow target of my workspace to S2, and check for changes. I think what I was intuitively looking for was a way to see that there were pending changes for the component in S2, without changing my current workspace flow target away from S1. However, now that I have had some more practice with this manual switch of the current flow target of my workspace it isn't difficult to use ... maybe I just need to get more familiar with the tools. |
![]()
Maybe you and your colleague should work on the same stream, but within your own respective workspaces. This way when you deliver changes they would automatically show as Incoming in her Pending Changes, and vice-versa.
|
![]() We would like to add support for auto-deliver/accept at the stream level if no conflicts are detected, but for for now everything has to flow through a workspace. Jean-Michel, Is there already a work item open for this enhancement? Our teams are very interested in this capability. It would also be helpful if the flows between streams could be unidirectional. With those two enhancements, we could specifies flows from older streams of our products to newer streams, such that we could apply a change to an older stream of the product, and it would automatically trickle up to as many of the later streams in the chain as needed, without proceeding through the rather onerous process of "Change flow target" > "Replace with latest from stream" > Accept change set > Deliver (rinse and repeat for every release you still support). Is there an easier way of doing this that I'm not aware of? The teams I have worked with tend to apply fixes to 3 or more old releases at a time, and with our previous SCM we just kept the files linked between releases so that changes were automatically propagated. Thanks, Jonathan Huestis |
![]()
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 06 '08, 1:08 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
There is an advanced form of the Pending Changes display, which you can
select through "preferences", that shows all of your flow targets, instead of just your "current" one. The main missing piece here is that you cannot just say "deliver to all" (that button is always greyed out in multi-target mode), but you can multi-select the targets you want to deliver to. If you'd like to see the "deliver all" button enabled in multi-target mode, please submit an enhancement request. Cheers, Geoff kludgeless wrote: jlemieuxwrote: |
![]()
Yes, please see 12021: Inheritance between streams.
There is no other way of doing this, and I agree that it would be nice to allow auto-accept/deliver. However, there is one caveat to the use-case that we will have to implement nicely, which is how to notify the team when an auto-deliver/accept failed because of conflicts. In your scenario, it's quite possible that to merge the change between the 3 releases someone will have to merge. In other simpler cases, like keeping a set of read-only components up-to-date in a stream, then merging isn't as much a problem. Or auto-delivering into an integration stream when a certain condition is satisfied. Jean-Michel We would like to add support for auto-deliver/accept at the stream level if no conflicts are detected, but for for now everything has to flow through a workspace. Jean-Michel, Is there already a work item open for this enhancement? Our teams are very interested in this capability. It would also be helpful if the flows between streams could be unidirectional. With those two enhancements, we could specifies flows from older streams of our products to newer streams, such that we could apply a change to an older stream of the product, and it would automatically trickle up to as many of the later streams in the chain as needed, without proceeding through the rather onerous process of "Change flow target" > "Replace with latest from stream" > Accept change set > Deliver (rinse and repeat for every release you still support). Is there an easier way of doing this that I'm not aware of? The teams I have worked with tend to apply fixes to 3 or more old releases at a time, and with our previous SCM we just kept the files linked between releases so that changes were automatically propagated. Thanks, Jonathan Huestis |
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.