Description - Mks.com

options
applicable to MKS Integrity Suite commands
DESCRIPTION
Some MKS Integrity Suite commands (si, im, aa, integrity) share general options, while all take certain universal options. This
reference page is provided as a guide to these common options.
Source Integrity: Specifying Members, Sandboxes and Projects
There are three types of Source Integrity commands, and therefore the way you specify the member varies:
1. Some commands can only be executed on members in the context of a sandbox, because they manipulate the member's working file.
These are noted as requiring a sandbox member..., such as si ci, si co, and si merge. These take a sandbox member, and you
may not perform the operation against a project member. If you try to specify a project for these commands, you will see an error
message.
2. Other commands do not manipulate a member's working file, and therefore can be performed directly in the context of a project. If you
specify a sandbox, it is simply used as a pointer to find the project itself. The fact that you specify the sandbox is only incidental.
These are noted as requiring a project member..., and most of the commands that say member... fall into this category; for example,
si updaterevision, si updatearchive, and si addlabel.
3. There are also some commands that perform differently depending on whether they are given a sandbox or a project. Examples for
this would be si diff and si edit.
You can explicitly specify either -P or -S options for most commands. For -
P you must specify a project or subproject, the -P option does not accept the filename of a sandbox. For -
S you must specify a sandbox or subsandbox, -S does not accept the filename of a project.
Source Integrity also allows for implicit sandbox selection. This means that you can use commands without explicitly specifying a -
S sandbox option, and Source Integrity determines the sandbox to operate on based on the directory you're working in.
For example, suppose you are working in the directory C:\test\sbx\sub1\sub2, and suppose you have a sandbox only in the \sbx
directory. Using the -S option to explicitly specify the sandbox, you might enter the following to check in a file:
si ci -S c:\test\sbx\project.pj header.c
Using implicit sandbox location to check in a file, you might enter:
si ci header.c
If the sandbox is not specified explicitly through -
S, Source Integrity tries to locate one by starting in the current working directory and seeing if there is a sandbox registered in that directory.
If there isn't, it searches up the directory tree until it either finds one, or until it reaches the root of the drive. In the example provided, Source
Integrity first determines there is no sandbox in \sub2, then \sub1, then finds the sandbox in \sbx and uses that sandbox.
Now suppose you have sandboxes in each of \sbx, \sub1, and \sub2. This implicit sandbox selection allows you to work with multiple
sandboxes in one command line entry, and without having to explicitly specify lengthy locations for each one. If you're working in the
C:\test\sbx directory and decide to check in files to each sandbox, for example, you might enter:
si ci header.c sub1\comp.c sub1\sub2\img.c
This checks in the file header.c to the sandbox at C:\test\sbx , checks in the file comp.c to the sandbox at C:\test\sbx\sub1, and
checks in the file img.c to the sandbox at C:\test\sbx\sub1\sub2.
A requirement for implicit sandbox location to operate correctly is that there can be no more than one sandbox (or subsandbox) registered in
a single directory. If you create two or more sandboxes in the same directory, the implicit sandbox location algorithm cannot unambiguously
determine which sandbox to use in that directory, and it prompts you to clarify by specifying the name of the sandbox that you want to use in
that case. In general, you shouldn't create multiple sandboxes in the same directory.
Note:
Certain si commands do not operate on Build sandboxes, which are created as read-only for the purpose of building a programming
artifact. Using inappropriate commands with a Build sandbox causes error messages to appear.
337 of 457