Teamwork and Configuration Management Teamwork and Configuration ManagementBy: S.P. Berczuk
Published in: C++ Report, July/Aug. 1997
Pages: 29-33, 72
Category: Configuration Management
Summary: Configuration management patterns and how they relate to organization. A revised version may be found online at http://www.enteract.com/~bradapp/acme, along with Appleton's PLoP '98 paper "Streamed Lines," on branching patterns for parallel development, and Cabrera's PLoP '99 paper "Patterns for Software Reconstruction."
Pages: 31-32
You want to checkpoint changes without making the changes available to the entire development team. You want to implement Code Ownership, but subsystems never work entirely in isolation. Provide developers a local revision control area to checkpoint changes at a granularity they are comfortable with. Developers should migrate changes to the shared version at reasonable intervals.
Pages: 32
Some development projects have infrequent integration that reflects considerable change. This can make it difficult to use Named Stable Bases. Allow developers to build current software periodically. Developers should be discouraged from having long intervals between check-ins. When you're using Private Versioning, the developer's private copy should be converted to a named stable base weekly.
Pages: 32-33
You're using Named Stable Bases. To balance the need for developers to use current revisions with the desire to avoid having dependencies change constantly, provide developers an independent workspace where they can maintain control of their own environment.