Taking Sandbox Snapshots
|
CLI EQUIVALENT
|
si snapshot
|
A snapshot captures the current state of a Sandbox, where each element in the Sandbox can be identified with a pre-existing entity in the repository on the Integrity Lifecycle Manager server. The Sandbox snapshot creates a project checkpoint that you can create a build Sandbox or development path from. The revision number of a checkpoint created by a snapshot includes the revision number of the last checkpoint. For example, if the last checkpoint of the project has a revision number of 1.1, then the revision number of the checkpoint created by the snapshot is 1.1.1.1.
To take a Sandbox snapshot, select a Sandbox, and then select > .
When you take a Sandbox snapshot, you can specify a state or a label for the snapshot, and apply it to all Sandbox members. A label is a unique text string assigned by you to identify the project checkpoint created by the snapshot. Labels cannot contain colons (:), square brackets ([ ]), or leading spaces. Additionally, they cannot have the same format as a valid checkpoint number.
In the GUI, checkpoints for inactive projects are not shown by default. If you want to see these checkpoints, select > .
The Sandbox snapshot displays as a branched project checkpoint in the Project History view.
|
|
• If working files are missing from the Sandbox, a warning displays listing the missing working files that will not appear in the snapshot. If you want to include those working files in the snapshot, cancel the operation, provide the working files (by resynchronizing the corresponding members), and then perform the snapshot.
• In the GUI, revisions that were created by taking a Sandbox snapshot are not shown by default. To see these revisions, select > .
|
Contents of a Sandbox Snapshot
The set of Sandbox elements captured in a snapshot includes the following:
• Sandbox members identified with an archive and working revisions the archive was created from
• Former members that were dropped but are still present in your Sandbox
• Sub Sandboxes identified by project name and type
• Former sub Sandboxes that were dropped but are still present in your Sandbox
Example
Steve has been assigned to create a build of the savings calculator. He uses a build Sandbox to perform the build. He discovers a readme file is missing from the checkpoint his build Sandbox is based on. Jen has added the readme file in a change package. Steve adds the readme file to his Sandbox using the change package and then takes a snapshot of his Sandbox to save the configuration.
Key Considerations
• To be included in the snapshot, you cannot have working file changes in the Sandbox.
• If the working file revision differs from the member revision, it is the working file revision that is included in the snapshot.
• Members without working files are not included in the snapshot.
• Former members that still have working files in the Sandbox directory appear as members in the snapshot.
• Former subprojects that are still in the Sandbox view appear as subprojects in the snapshot.
• Integrity Lifecycle Manager always uses the actual name of the member working file for the snapshot.
• You cannot take a snapshot of a sparse Sandbox.
• The Snapshot Sandbox command is performed on the entire Sandbox independently of the filter used to display the contents of a Sandbox.
• You can compare differences between a project checkpoint created by a snapshot and another project checkpoint (including checkpoints created by a snapshot) in the project history, but you cannot compare differences with the Sandbox contents.
• To specify an existing development path when taking a Sandbox snapshot, you must use the CLI. For more information, see the CLI man pages.
• Members of a Sandbox need to be associated with a corresponding archive on the Integrity Lifecycle Manager server.
• When recursing into sub Sandboxes, the snapshot represents exactly the same directory structure and files of your Sandbox. All subproject elements become the same type and shared subprojects of different types become shared subprojects of the same type.
When you take a snapshot of a Sandbox recursively that contains sub Sandboxes, the snapshot creates a checkpoint for the sub Sandboxes based on the last checkpoint of the master project (if one exists), not on the current subproject in your Sandbox. Member revisions are unaffected.
Using Sandbox Snapshots in a Development Environment
The recommended scenario for when to take a Sandbox snapshot in a development environment is as follows:
1. You are in a situation where you are 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. Take a snapshot of the Sandbox.
4. Create a development path from the project checkpoint that corresponds to the snapshot.
5. Create a variant Sandbox from the development path you created, and then continue work on that development path.
|
|
From the CLI, you can specify an existing development path at the time you take the snapshot. For more information, see the CLI man pages.
|
Using Sandbox Snapshots in a Build Environment
The recommended scenario for when to take a Sandbox snapshot in a build environment is as follows:
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. Resynchronize the required revisions to fix the build (you can use Resync CP).
Take a snapshot of the Sandbox, and use the project checkpoint created by the snapshot to recreate the build in the future using a build Sandbox, instead of using the original project checkpoint.
