The Source Integrity Professional Edition User Guide - MKS

Understanding Source Integrity
Locking in
Variant
Sandboxes
remove or add members
set the development path
However, 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 that merged file back into
the build sandbox)
query for differences between project revisions, such as changes
to a project since it was last checkpointed
calculate dependencies, but you cannot add dependent files to
the project
update sandbox attributes
Source Integrity can manage access to source files by locking
revisions in the name of developers who check them out. This
provides a level of security, as it discourages two people from
working on the same revision at the same time.
When developers are following different development paths,
however, this kind of security can become inconvenient. Two (or
more) developers, working along different development paths, may
want to lock the same revision for different purposes.
Even though development paths are logically separate, Source
Integrity maintains one revision history for each source file, in a
corresponding archive. A revision can only be checked out locked by
one Source Integrity user. Conflicts can arise from this.
Those working in variant sandboxes are forced to lock revisions
that might be needed by developers working in standard
sandboxes.
Similarly, those following one development path would lock out
those following a different path.
To accommodate developers following different development paths,
Source Integrity will suggest to branch an archive. It does this
whenever a check-out operation would lock out other developers,
who might need access to the revision.
26 Source Integrity Professional Edition