Single-stream projects
For most organizations, a parallel development environment consisting of private and shared work areas makes sense. However, small teams of developers working together closely may prefer a serial development environment. UCM supports this by letting you create a single-stream project. A single-stream project contains one stream, the integration stream, and does not allow users to create development streams. When developers join a single-stream project, they create a view attached to the integration stream.
You may want to use a single-stream project during the initial stage of development when several developers want to share code quickly. When the development effort expands and you need a parallel development environment, you can create a multiple-stream project based on the final baselines in the single-stream project.
- Developers who work in dynamic views see each other’s work as soon as they check in their files. Developers who work in snapshot views see each other’s work as soon as they check in their files and update their views. In a multiple-stream project, developers see each other’s changes only during deliver and rebase operations.
- Developers have a simplified work environment. Because all work is done on the integration stream, developers do not need to maintain a development stream and two views, one attached to the development stream and one attached to the integration stream. In addition, developers do not need to perform deliver or rebase operations.
- Your role as integrator is simplified. Because developers work on the same stream and see each other’s changes immediately, you do not need to create baselines frequently. In contrast to a multiple-stream project, developers do not depend on baselines to integrate their work. The primary purpose of baselines in a single-stream project is to identify major milestones.
- Developers have limited support for sharing files simultaneously. Although multiple developers can check out an element in the same stream at the same time, only one developer can reserve the checkout. A reserved checkout guarantees the developer’s right to check in a new version of the element. All other developers must check out the element as unreserved, which means that they cannot check in their versions until after the reserved checkout has been checked in or canceled. Developers with unreserved checkouts must merge their changes with the changes made by the reserved checkout.
- Because changes are shared as soon as developers check in their files, developers assume the full responsibility for testing their work and must be extremely vigilant to ensure that they do not introduce bugs to the project. In contrast, a multiple-stream project allows the integrator or a software quality engineering team to perform extensive testing of new baselines on a dedicated testing stream and to recommend baselines only after they pass those tests.
- Because changes are shared as soon as developers check in their files, developers might keep files checked out longer than they would in a multiple-stream project. If a view is lost, all changes made but not checked in that view are also lost. Therefore, have your DevOps Code ClearCase® administrator frequently back up views for single-stream projects.