si snapshot
records the state of a sandbox.
Synopsis
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]]
Description
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 1.1.1.1. 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 Hilfe-Center.
Options
This command takes the universal options available to all
si commands, as well as some general options. See the
options reference page for descriptions.
• --targetDevpath=value
specifies the development path to create the snapshot from. With this option you can only specify an existing development path.
• --author=value
specifies the author of the snapshot revision.
• -d
• --description value
specifies the description for the snapshot revision.
• --descriptionFile=value
specifies a file containing the description for the snapshot revision.
• -L
• --label=value
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.
• --[no]notify
provides a notification when the snapshot has been created.
• -s
• --state=value
specifies the state for the project checkpoint created by the snapshot.
Diagnostics
See the
diagnostics reference page for possible exit status values.
Preferences
Using
si setprefs or
si viewprefs, you are able to set or view the preference keys for this command.
See Also
• Commands:
si archiveinfo,
si memberinfo,
si mods,
si print,
si revisioninfo,
si rlog,
si sandboxinfo,
si viewhistory,
si viewlabels,
si viewproject,
si viewprojecthistory
• Miscellaneous: