Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Method 3: Mainline Plus Sandboxes
To allow the team to work in parallel, we can provide them with a copy of the system in a separate work area known as a sandbox. Changes made in the sandbox have no impact on the mainline.
Now making changes is a multiple-step process:
Copy:
- Lock.
- Copy mainline to empty sandbox.
- Unlock.
Change:
- Make changes in sandbox.
Integrate:
- Lock.
- Integrate sandbox into mainline.
- If integration fails, restore the prior version.
- Back up the system.
- Unlock.
The process looks like Figures 3.
){kind=link}
Figures 3 Integration using sandboxes.
One aspect of this process is tricky: "Integrate sandbox into mainline." You can't just copy the sandbox in, or you would lose changes made by others.
Integration is easy in one case: If the file is identical in both the mainline and the sandbox, you don't do anything.
Three cases are more interesting:
The file is in the sandbox but not the mainline.
The file is in the mainline but not the sandbox.
The file is in both mainline and sandbox, but differs.
In each of these cases, the integrator must make a decision about which files—or which parts of files—should be used. (More sophisticated schemes and better tools can help with the process.)
Successful integration means that all tests must still pass when you're done integrating. If you're unable to integrate successfully, you can try later, or clear out your sandbox and start over.
This approach has these consequences:
Pairs can work in parallel.
Integration is more difficult than it was in the previous scheme.
If integration fails, the mainline can be restored from its last backup.