User Guide - Mks.com

Working With Sandboxes
Preventing Conflicts With Other Development Paths
Development paths can conflict when developers working on different
paths need to work on the same revision of a file. There is also the potential
for conflict when development paths access the same member histories.
For example, the current version of a project includes utility.dll,
version 1.4 and the variant sandbox contains utility.dll, version 1.3.
Both versions are stored in the same member history.
Other potential conflicts include:
a developer with a variant sandbox locks revisions needed by
developers working in regular sandboxes
work on one development path locks out those working on a different
development path
To prevent potential conflicts, Source Integrity assumes that locking a
revision is appropriate when you check out a revision when working in a
variant sandbox. You are further prompted to branch the member history
when you check out a revision with a potential conflict, for example:
The project Apex.pj, version 1.2 was checkpointed at version 1.2 and
included utility.dll version 1.2 and library.lib version 1.3.
A development path is created for Apex.pj, version 1.2.1.1 and
includes the same file versions for utility.dll (version 1.2) and
library.lib (version 1.3).
Branching the member history gives each development path its own copy
of the revision.
Creating a Development Path
A variant sandbox uses a project checkpoint as the starting point for new
development. In Source Integrity, you define a new development path for
the variant sandbox.
The development path:
identifies a new direction of development
includes a new revision history
keeps changes separate from the main development path or trunk
You must first create and name the development path, and then create the
variant sandbox.
147