User Help > Managing Your Personal Workspace in a Sandbox > Sandboxes Overview
 
Sandboxes Overview
A Sandbox is a private workspace that resides on the client machine and mirrors the content of a project on the server. Although it looks and acts like the project it mirrors, a Sandbox is actually a collection of pointers to its real-life counterparts in the master project. Sandboxes allow you to work locally in your own workspace, without interfering with the work of others.
Different types of Sandboxes are available for different types of development.
Normal Sandboxes are useful for the sequential development of a project over the long or short term.
Variant Sandboxes are useful for branching off the main development path.
Build Sandboxes are useful for testing a specific revision of the project.
Using Variant Sandboxes
A variant Sandbox is based on a specific development path of a project. When you create a variant Sandbox, you choose the development path to use. In the variant Sandbox, you can see the current state of the project along that development path and the changes made by other developers using it.
When a variant Sandbox is created for the first time, it is also created for all subprojects, reserving the assigned name as a unique identifier and ensuring no two paths can share the same name.
Conflicts can occur when developers working on different paths need to work on the same revision of a file. For example, one developer could be working in a regular Sandbox that includes utility.dll, version 1.4 and another developer could be working in a variant Sandbox that contains utility.dll, version 1.3. Both versions are stored in the same member history.
To prevent potential conflicts, the first time you check in a member from a variant Sandbox, you are prompted to branch the member history. Branching the member history gives each development path its own copy of the revision.
Using Build Sandboxes
After major milestones, such as product releases, you might want to recreate a static version of an entire project as it existed at some point in the past. You create a build Sandbox to build or test the project, but not to begin further work along a new development path. Build Sandboxes could be used for quality assurance or production to distribute files in a fixed configuration.
A build Sandbox is a Sandbox associated with a particular project checkpoint and has no development path (since it is static and not meant for further development). No further development can be carried out in a build Sandbox.
For example, if a build manager needed to burn a CD of a special build that did not include a certain feature, he could use an earlier checkpoint to create a build Sandbox on the CD burning system.
Within a build Sandbox, you can:
change labels and states
resynchronize your Sandbox
compare a member revision in the build Sandbox to another revision
merge a member revision in the build Sandbox with another revision (of course, you cannot check a merged file back into the build Sandbox)
check for differences between checkpoints, such as changes to a project since it was last checkpointed
When you create a build Sandbox, you choose the project checkpoint to base the build Sandbox on.
However, with a build Sandbox, you cannot:
check out, lock, or check in members
add or remove members
set the development path
freeze or thaw members
checkpoint the master project
modify project or member attributes
revert members
set the member revision
Each of these represents further development, which requires a normal or variant Sandbox.