CLI Reference > Configuration Management Commands > si snapshot
si snapshot
records the state of a sandbox.
si snapshot [--targetDevpath=value] [--author=value] [-d|--description=value] [--descriptionFile=snapshot] [-L|--label=value] [--[no]notify] [--[no]failOnAmbiguousProject] [-s|--state=value] [-S|--sandbox=value] [--hostname=server] [--port=number] [--password=password] [--user=name] [(-?|--usage)] [(-N|--no)] [(-Y|--yes)] [--[no]batch] [--cwd=directory] [--forceConfirm=[yes|no]] [(-g|--gui)] [--quiet] [--settingsUI=[gui|default]] [--status=[none|gui|default]]
si snapshot records a capture of 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 Windchill RV&S Server. The Sandbox snapshot creates a project checkpoint that you can create a build Sandbox or a 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 head revision of the project is 1.1, then the project checkpoint created by the snapshot will be The Sandbox snapshot displays as a branched project checkpoint in the project history.
si snapshot records the state of a sandbox, while si checkpoint records the state of a project. Checkpointing is recommended for recording milestones during the development of a project; however, there may be situations where you may need to take a snapshot of a sandbox to record the state for later use.
The state of a sandbox is defined by its set of elements, which include the following:
sandbox members identified with an archive and working revision from which the working file was created
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
Note the following about how si snapshot handles the set of Sandbox elements:
To be included in the snapshot, all working files must be checked in. There must be no 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 with no 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 directory appear as restored subprojects in the snapshot.
For more information on Sandbox snapshots, see the Windchill RV&S Help Center.
This command takes the universal options available to all si commands, as well as some general options. See the options reference page for descriptions.
specifies the development path to create the snapshot from. With this option you can only specify an existing development path.
specifies the author of the snapshot revision.
--description value
specifies the description for the snapshot revision.
specifies a file containing the description for the snapshot revision.
specifies a label for the snapshot revision. Note the following about using labels:
Labels cannot contain colons(:), square brackets ([ ]), or leading spaces.
Labels cannot have the same format as a valid revision number.
Labels that include spaces must be enclosed by quotes.
PTC recommends not using hyphens (-) in labels. Using hyphens may cause some si commands to fail.
provides a notification when the snapshot has been created.
specifies the state for the project checkpoint created by the snapshot.
See the diagnostics reference page for possible exit status values.
Using si setprefs or si viewprefs, you are able to set or view the preference keys for this command.
See Also
si archiveinfo, si memberinfo, si mods, si print, si revisioninfo, si rlog, si sandboxinfo, si viewhistory, si viewlabels, si viewproject, si viewprojecthistory
ACL, diagnostics, options, preferences