User Guide - MKS

Controlling Sandboxes
the current revision of the subproject in your sandbox. Member
revisions are unaffected.
When you snapshot a sandbox non-recursively the subproject
elements refer to the exact type they were in the sandbox at the time
the snapshot is performed, so configured subprojects remain
configured. For more information, see “Configuring a Subproject” on
page 126.
The following is the recommended scenario for when to take a sandbox
snapshot in a development environment:
1 You are in a situation where you have been working in a regular
sandbox, but should be working in a variant sandbox.
2 Instead of checking in your changes to the main development path,
check in (or merge in) your changes on a branch.
3 Snapshot the sandbox.
4 Create a development path from the project revision that corresponds
to the snapshot (see “Creating a Development Path” on page 141).
5 Create a variant sandbox from the development path you created, and
then continue work on that development path.
TIP
From the CLI, you can specify an existing development path at the time you
take the snapshot. For more information, see the Source Integrity Enterprise
Edition CLI Reference Guide.
The following is the recommended scenario for when to take a sandbox
snapshot in a build environment:
1 Checkpoint the project.
2 Create a build sandbox for the build.
3 The build fails, but since development has continued, some of the
required members are at later revisions than the last checkpoint.
4 Perform a resynchronize of the required revisions to fix the build (you
can use resync cp).
5 Snapshot the sandbox, and use the project revision created by the
snapshot to recreate the build in the future using a build sandbox,
instead of using the original project checkpoint.
255