A Stream is a repository object that includes one or more components. Streams are typically used to integrate the work done in repository workspaces. As a team member, we would deliver changes from our repository workspace into the stream and accept other team members' changes from the stream into our repository workspace.
A Component is a collection of artifacts (analogous to a module in conventional software development). We can make any component in the repository as a part of a stream. Typically, the components in a stream are related functionally so that they are grouped together. After we have created a stream, we can use the stream editor to manage components.
We can create a stream to hold several components with different versions that represent an important configuration of a system. A milestone release or development version of the BookManager project is an example of such a configuration. When we deliver change sets from our workspace to a stream and accept other team members' change sets from the stream, the stream represents the current state of the team's development effort.
Imagine the stream as a concept similar to "branch" in other version control systems, but with many more capabilities. A component is a collection of source files, documents, or other artifacts; and a stream contains a set of versioned components. By using multiple streams, we can start working on different components with different versions. This is an extremely helpful scenario when we want to do tasks such as the following:
- Developing the next major version on a new stream
- Making a project release ready by working on a release branch
- Maintaining older versions of components on a maintenance branch
- For large projects, document components can be in a single document branch
An example may look like the following diagram:
We can imagine several other possibilities to organize the code into components and components into different streams. In the previous diagram, we can see how the BookManager project is organized into components, namely BookManager Project v2 and BookManager Doc v1. In a similar way, we can imagine that the BookManager project also has another stream called BookManager-Release-v0.1 that deals with all the versioned components used for a specific release.
In the previous chapter, we imported the source code from the Subversion version management dump file and set up the BookManager repository and component. Now, we will create the bare bones of a BookManager Doc component (as shown in the following screenshot) and add it to the team source control, then add this new component to the BookManager Project (dev) stream.
We already set up the component BookManager Doc as an Eclipse project, and in the next step, we will add the component to the team source control and share it with the entire team. In this component, there are two folders: design-doc, to contain the architecture and design documents; and install-doc, to contain application installation documents.
To share the BookManager Doc project into the team source control, select the BookManager Doc project, right-click, and select Team | Share Project as shown next:
As seen in the previous screenshot, from the Share Project dialog, select Jazz Source Control and click on Next to select further details. We can either select an existing workspace or create a new one. For now, we will use the existing repository BookManager Project and click on New Component. Enter the name of the component and click on OK, as shown next:
In the next dialog (refer to the following screenshot), we can see all the resources that need to be added to the team repository and a set of resource ignore patterns. The dialog provides a good interface to manage the ignore patterns of the resources. When we are not sure of the resources to add, check the Show all resources option, then selectively choose which resource to ignore.
Once we've specified the resources to ignore, click on Finish and Rational Team Concert will add the needed artifacts to the repository and make a change list for us. The change list shows the files and folders that are affected by this change. We can accept the change and deliver it to the stream from the context menu of the Pending Changelists view, as shown next:
Once the component is delivered, we can see that the repository workspace added the BookManager Doc component. The component has the baseline information attached to the view. In our case the baseline says 1: Initial Baseline.
Here we have seen how to share the code from client to team source control and create a new BookManager Doc component. Now this component is available for any team member to view and work on. When a user who is authorized to see the project sources, for example, fgerhardt (see the setup at the beginning of the chapter), logs in to the client and loads the BookManager project, he can see the BookManager Doc component as shown next. This user can load the components into the local repository and start working on them when needed.
