Implementing multi-stream in Jazz Source Control
Multi-stream development in IBM Rational Team Concert is a concept where more than one stream is used in a project. Here data flows from one stream to another stream which is different from the usual workspace to stream flow. It allows a project to use parallel development. There can be many scenarios where more than one streams are required. For example, a team may want one stream for purely developmental work and another stream for fixing the bugs of production. Later on, perhaps once a month or so, the code from these streams can be merged.
Setting up multi-stream will allow the developers to carry on their work without getting interrupted by production bugs and vice versa. So whenever the next release has to happen, the production bug fixes can be merged with development code and sent for release.
This article provides step-by-step instructions on how to implement multi-stream in Jazz Source Control. It will show the changes flowing from one stream to another.
Pre-requisites
- Basic knowledge of RTC SCM
- Running JTS Server and Eclipse client
- Connected project in Eclipse Client with three streams, all loaded with component and project
Scenario
We have three streams – a development stream, a bug-fix stream, and a main integration stream. We also have two users – User1 (Development team) and User2 (Bug Fix team). The Development team writes the code and sends it to the main integration stream regularly. The Bug Fix team fixes bugs and then sends the code to the main integration stream on a weekly basis, typically the final day of the week. Updates in the main integration stream flow to both development and bug fix streams. Whenever merging is required, it is performed. Code merging or resolving conflicts is not shown in this article. For information on resolving conflicts, refer to the article “Jazz Source Control – Resolving Conflicts“.
Flow diagram of the scenario can be represented in the below figure. Flow diagrams provides a pictorial representation between the flow of change sets from one stream/repository to another stream/repository.
Implementation
We have the following three streams as shown in the below figure.
Repository workspace for User1 flows with Development stream.
Repository workspace for User2 flows with Bug Fix stream.
Note: It is assumed that User1 has already shared a project in the Development stream and created a snapshot. From that snapshot, the Bug Fix Stream is created. To create a stream from the snapshot, right click on the stream and select Show -> Snapshots. Once the snapshot is listed, right click on the snapshot and click on New -> Stream from Snapshot.
For streams to flow changes directly to another stream, ‘Flow Targets’ need to be defined. As the name suggests, a flow target is the target where the change sets will flow. Flow targets can be streams or repository workspaces.
Login with User1. Open the stream by double clicking on it and scroll down to Flow Targets. Add the target stream. Here we have Main Integration stream as the target of the Development stream. So User1 opens Development stream and adds Main Integration stream in Flow Target. This implies that whenever a change set is delivered to Development Stream, it will flow to Main Integration Stream.
Since the Bug Fix stream flows the changes only once a week, we will not define its flow target now. It will be defined only when the changes will be required to flow.
Note: If flow targets are defined, changes from one stream to another will flow continuously.
Once the flow target is defined, go to the Show -> Pending Changes of the Development stream in Eclipse client of User1.
A stream to stream outgoing change will display under the Pending Changes view. Show -> Pending Changes is required once for every stream which has flow target defined. By doing this, a “Stream to Stream” flow appears in Pending Changes view.
As shown in the figure below, there are some outgoing changes from the Development stream to the Main Integration stream. These changes are the change sets which were delivered to the Development stream. Since a flow target is defined for the Development stream, the changes will flow to the Main Integration stream. Deliver the changes of the Development stream to Main Integration stream.
The project is now present in the Main Integration stream as well. This “Stream to Stream” flow has been achieved using flow targets.
Now, User1 makes some changes in one file and delivers it to the Development stream. A similar flow will happen and using the “Stream to Stream” flow, changes will flow to Main Integration stream.
Now User2 logs in into his Eclipse client and starts fixing bugs (editing code files). These changes are continuously flowing to the Bug Fix stream, but not to the Main Integration stream. On the last day of the week, when changes from the Bug Fix stream needs to flow to the Main Integration stream, User2 will define the flow target of the Bug Fix stream as Main Integration stream by following the same process as described above.
Go to Show -> Pending Changes on the Bug Fix stream. The “Stream to Stream” flow (Bug Fix stream to Main Integration stream) will appear in the Pending Changes view. All the change sets of the Development stream which were delivered to Main Integration will show as incoming changes for Bug Fix stream. The change sets delivered to the Bug Fix stream will show as outgoing.
Note: Flow targets are always bi-directional. That means if we define the flow target of Stream1 as Stream2, then the changes from Stream1 will flow to Stream2 and the changes from Stream2 will also flow to Stream1.
User2 accepts all the incoming changes, performs a merge (if required), and then delivers his outgoing changes to the Main Integration stream.
Now as soon as User2 accepts the changes from the Main Integration stream to the Bug Fix stream, an incoming change starts showing from the Bug Fix stream to the repository workspace of User2 (Bug Fix Stream Workspace_User2). This happens because when we create a repository workspace, we select its flow target by using the option Flow with a stream. This defines the stream as the flow target of the repository. Since flow targets are bi-directional, the changes flow from the stream to the repository workspace.
User2 accepts all the changes in to his repository workspace. This implies that whatever changes User1 (from the Development team) performed, flows to the Main Integration stream then to the Bug Fix stream and then to the Bug Fix Stream Workspace_User2. So now, User2’s repository workspace has the Development team’s changes. However, User1 still has to get the bug fixes made by User2.
After performing all the synchronization and flow changes, User2 will remove the Main Integration stream as the flow target of Bug Fix. Removal of a flow target is required in this case because if the flow target is not removed, the change sets will continuously be flowing towards the Main Integration stream (and if a deliver operation is done, intentionally or unintentionally, the changes will flow to Main Integration and from there to the Development stream). According to our scenario, the changes of the Bug Fix stream should flow only once a week, change set flows on any other day may create issues.
Now User1 will log in. “Stream to Stream” flow will show incoming changes from the Main Integration stream to the Development stream. These changes are the change sets delivered by User2 to the Bug Fix stream and then to the Main Integration stream. User1 will accept all the incoming changes coming from Main Integration stream to the Development stream, and then from the Development stream to their own repository workspace (Development Stream Workspace_User1). At this point, merges should be performed if required.
Now all the repository workspaces and all the streams are in sync. That is, all the changes made by User1 and User2 are in sync.
Change Flow Target
There is a temporary way of changing the flow target. If a user wants to deliver one or more change sets to a different stream just once, they can do so from Pending Changes view using Change Flow Target.
A user can select either a stream or a workspace as the flow target. These changed flow targets will be shown in italics because they are not the default ones.
Once the changes are delivered, the user can revert the change made to the flow target by following the same procedure.
Default and Current Flow Targets
If multiple flow targets are defined, one of them can be made the default and one as the current. Any one flow target can be made both default and current.
For more information
About the author
Shuchita Tripathi is working as an IBM Rational Product Specialist in Tata Consultancy Services Ltd. within Technology Excellence Group(TEG). The Tata Consultancy Services IBM Rational Technology Excellence Group (TEG) is a team of experts on Rational software products and technology. She has been using various tools like RTC, RRC, RQM and DOORS and has conducted several trainings in various locations. She is IBM Certified Specialist in Rational Team Concert and Rational Quality Manager and IBM Certified Deployment Professional in DOORS. She can be contacted at shuchita.tripathi@tcs.com.
Copyright © 2014 Tata Consultancy Services