Figure I-1. A codeline and its components
Figure I-2. Populating a workspace from different codelines
Figure I-3. Branching a single file and merging with the trunk
Figure I-4. Branching an entire codeline
Figure I-5. Codeline diagram notation
Figure 2-1. The interactions between elements of the environment
Figure 3-1. The SCM pattern language
Figure 3-2. Codeline-related patterns
Figure 3-3. Workspace-related patterns
Figure 4-1. A merge can be messy
Figure 4-2. Staircase branching (or a cascade)
Figure 4-3. Mainline development
Figure 5-1. Long-running tests have mixed value.
Figure 5-2. A stable but dead codeline
Figure 5-3. A Very Active but very Useless Codeline
Figure 5-4. An active, alive codeline
Figure 5-5. Labeling Named Stable Bases
Figure 6-1. Combining changes at once
Figure 6-2. Integrating each change as it happens
Figure 6-3. Sharing Some Components between Workspaces
Figure 7-1. A workspace is created from many things.
Figure 7-2 Populate your workspace from a repository.
Figure 7-3. Version tree for a workspace
Figure 8-1. The build integrates changes from everyone.
Figure 8-2. Components of the private system build
Figure 9-1. Integration can be difficult.
Figure 9-2. An Integration Build Process Assembles the Pieces.
Figure 10-1. Vendor releases and your releases are not in sync.
Figure 10-2. Third party codeline
Figure 12-1. Each codeline needs different rules.
Figure 16-1. Each decision leads to more choices, until you pick the solution.
Figure 16-2. Using the codeline for staging generates a lot of noise.
Figure 17-1. Doing all your work on the mainline
Figure 17-2. Create a branch when you ship.
Figure 17-3. Staircase of dependent branches
Figure 17-4. Release Line
Figure 18-1. Release-Prep Code Line
Figure 19-1. Some tasks are for the future.
Figure 19-2. Creating a release line too early is troublesome.
Figure 19-3. Task branch