looking for advice on multi-stream development
We have a core team that is constantly delivering changes to trunk. There is another side team that would like to port our trunk code to another platform. The core team doesn't want to see changes from the porting team until the porting team is done at the end of the release. Similarly, the porting team doesn't want to see a constant flow of change sets from trunk, they would prefer to have it be stable for a while for their porting effort, then at the beginning of their iteration "manually" accept all the change sets waiting on trunk, then have it be stable for their next iteration, etc. And both teams want to share code within their teams using RTC SCM.
What would you recommend the setup be in RTC SCM for the porting team? I am familiar with simple branches (the core team does a simple branch from trunk where fixes can go). Pointers to tutorials/examples would be welcome.
Thanks!
What would you recommend the setup be in RTC SCM for the porting team? I am familiar with simple branches (the core team does a simple branch from trunk where fixes can go). Pointers to tutorials/examples would be welcome.
Thanks!
2 answers
https://jazz.net/library/article/40
There is an article on multi-stream development that I think would help you decide how to set up your streams. I think what your project needs is a side-stream/branch for the side team. You can do this by duplicating the stream that contains all the changes from the core team. The side team can deliver to the new stream and someone on the side team will have to accept changes from the core stream.
The core team can even create baselines to indicate points where they think the code is stable for the side team to accept.
There is an article on multi-stream development that I think would help you decide how to set up your streams. I think what your project needs is a side-stream/branch for the side team. You can do this by duplicating the stream that contains all the changes from the core team. The side team can deliver to the new stream and someone on the side team will have to accept changes from the core stream.
The core team can even create baselines to indicate points where they think the code is stable for the side team to accept.
This is what I came up with. Is this what you meant by a side-stream/branch?
- The trunk stream already exists. I created a new stream named "port", and added to it all the components from the trunk stream (with the same baselines).
- initially created a workspace for a member of the port subteam that flows with the port stream.
- have the port stream catch up with trunk (only one person in the subteam needs to do this) (it is helpful if you don't have any pending outgoing changes to the port stream already): In the Pending Changes view in RTC, right click on the workspace name and change the flow target to trunk. After a moment, the Pending Changes view will update with new Incoming and Outgoing changes. Only accept the incoming changes, which will pull new things from trunk into my workspace. I should accept all incoming changes. Do not deliver yet. Now, change the flow target of the workspace back to "port". All the change sets I accepted from trunk will now appear as Outgoing changes to the port stream. Deliver those outgoing changes. Those changes are now shared with the port subteam.
- deliver changes from the port stream to trunk (only one person in the subteam needs to do this) (again, it is helpful if I don't have any pending outgoing changes to the trunk stream already): In the Pending Changes view in RTC, change the workspace's flow target to trunk. After a moment, my Pending Changes view will update with new Incoming and Outgoing changes. All the change sets I authored in / accepted from port stream will now appear as Outgoing changes to trunk. Deliver those outgoing changes. I should deliver all outgoing changes. Those changes are now shared with the overall whole team and are now merged with trunk.
So the bottom here is to use a single workspace, then flow that workspace with different streams at different times, then I can push and pull change sets from one stream to another via my workspace.
- The trunk stream already exists. I created a new stream named "port", and added to it all the components from the trunk stream (with the same baselines).
- initially created a workspace for a member of the port subteam that flows with the port stream.
- have the port stream catch up with trunk (only one person in the subteam needs to do this) (it is helpful if you don't have any pending outgoing changes to the port stream already): In the Pending Changes view in RTC, right click on the workspace name and change the flow target to trunk. After a moment, the Pending Changes view will update with new Incoming and Outgoing changes. Only accept the incoming changes, which will pull new things from trunk into my workspace. I should accept all incoming changes. Do not deliver yet. Now, change the flow target of the workspace back to "port". All the change sets I accepted from trunk will now appear as Outgoing changes to the port stream. Deliver those outgoing changes. Those changes are now shared with the port subteam.
- deliver changes from the port stream to trunk (only one person in the subteam needs to do this) (again, it is helpful if I don't have any pending outgoing changes to the trunk stream already): In the Pending Changes view in RTC, change the workspace's flow target to trunk. After a moment, my Pending Changes view will update with new Incoming and Outgoing changes. All the change sets I authored in / accepted from port stream will now appear as Outgoing changes to trunk. Deliver those outgoing changes. I should deliver all outgoing changes. Those changes are now shared with the overall whole team and are now merged with trunk.
So the bottom here is to use a single workspace, then flow that workspace with different streams at different times, then I can push and pull change sets from one stream to another via my workspace.