si co

CLI Reference > Configuration Management Commands > si co

si co

checks out members into working files in a Sandbox

Synopsis

Description

si co checks out members, typically for modification. For example,

si co c:/Documentation/Man_Pages/xml_man/si_add.1.xml

If no members are specified, si co applies to all Sandbox members.

Check out is an operation that extracts the contents of a revision in an archive and copies it to a working file. You can check out any revision by specifying either its revision number or label. By default, the member revision is used. If an existing revision other than the head revision is specified, a branch from that revision is created if you specify to do so.

Use the si resync command to get a read-only copy of a member in your project.

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.

• --mergeType=[confirm|cancel|automatic|manual]

specifies how you want merge changes from the working file in your Sandbox into the working file that will be created upon check out.

--mergeType=confirm prompts you to confirm a merge type.

--mergeType=cancel cancels the selected merge.

--mergeType=automatic completes the merge process without launching the Visual Merge tool.

While Integrity Lifecycle Manager and Visual Merge are capable of performing automatic merging, PTC cannot guarantee that the merged results are “correct”. PTC recommends that you examine and test the merged results before checking them into the repository.

--mergeType=manual completes the merge operation through the Visual Merge tool or a third party merge tool, depending on your Difference and Merge Tool preferences. The merge tool launches, displaying the revisions you want to merge. For more information on the Visual Merge tool, refer to the Integrity Lifecycle Manager Help Center.

specifies what to do when conflicts occur during a merge.

--onMergeConflict=confirm prompts you to confirm a merge conflict option.

--onMergeConflict=cancelcancels the merge.

--onMergeConflict=mark marks the revisions indicating that merging is required without completing all of the merge related tasks. This provides time you may need to investigate conflicts or consult on editing or difference blocks before finishing the merge.

--onMergeConflict=launchtool launches the Visual Merge tool to resolve the conflicts, all non-conflicting blocks will already have been applied.

--onMergeConflict=highlight indicates conflicts in the file with the following characters: "<<<<<<" and ">>>>>>".

--onMergeConflict=error indicates merge conflicts with an error message prompt.

--onMergeConflict=launchtool does not require the -g or --gui options.

• -l

--[no|auto]lock

controls whether to create locks on members.

--lock means always lock the member.

--nolock means never lock the member.

--autolock means lock the member based on the locks policy. For information on the locks policy, contact your administrator.

• --[no|confirm]lockOnFreeze

controls whether to lock the specified member even if it is frozen.

--lockOnFreeze means always lock the specified member.

--nolockOnFreeze means never lock the specified member.

--confirmlockOnFreeze means always ask before locking the specifies member.

• --[no|confirm]merge

controls whether to merge changes from the working file in your Sandbox into the working file that will be created upon check out.

--merge means always merge.

--nomerge means never merge.

--confirmmerge means always ask before merging. When asked to confirm the merge, you have the option of specifying y, n or d. Specifying d displays the differences between the member's working file and the revision that is being checked out.

• Specifying the --yes or --no options automatically answers y or n to the confirmation question, and also automatically answers y or n to all questions asked

• By default, Integrity Lifecycle Manager prompts you for the type of merge (manual or automatic) to perform and what action to take if a conflict is encountered.

• --lockType=[exclusive|nonexclusive|auto]

specifies the type of lock obtained on checkout.

--lockType=exclusive obtains an exclusive lock on the member. Exclusive locks enable only one member at a time to lock a specific revision.

--lockType=nonexclusive obtains a non-exclusive lock on the member. Non-exclusive locks enable multiple users to check out the same revision for editing.

--lockType=auto obtains a lock on the member based on the locks policy. For information on the locks policy, contact your administrator. If the locks policy does noe require a lock, but the --lock option is set, a non-exclusive lock is obtained.

• --[no|confirm]downgradeOnLockConflict

controls whether to downgrade your lock to non-exclusive if another user has an exclusive lock on the revision.

--downgradeOnLockConflictmeans always downgrade.

--nodowngradeOnLockConflict means never downgrade.

--confirmdowngradeOnLockConflict means always ask before downgrading.

• --[no|confirm]moveLock

moves any lock you have on a revision in the same development path to the member revision, including the change package associated with the lock operation. Since you can only have one lock per member per development path, if you already have another revision locked, you need to move that lock to the member revision in order for the check in to succeed. The downgradeOnLockConflict option determines what happends if the member revision already has an exclusive lock. You also need to move your lock if it is associated with a different change package than the one you are using for the check out operation.

--moveLock means always move the lock.

--nomoveLock means never move the lock.

--confirmmoveLock means always ask whether to move the lock.

• -u

• --unlock

keeps the member unlocked, and is equivalent to --nolock.

• --[no]update

controls whether to update the project's member revision to the checked out revision.

In a variant Sandbox, specifying si co --noupdate --branchVariant member updates the member revision.

• --[no|un]expand

controls whether to expand, unexpand, or ignore keywords in the member file. Keyword expansion is only available in text archives, not binary archives. For descriptions of the Integrity Lifecycle Manager keywords, see the Integrity Lifecycle Manager Help Center. Possible keywords are:

$Author: Taherali, Khuzema (ktaherali) $
$CompanyInfo$
$Date: 2017/03/02 16:03:05IST $
$Header: si_co.dita 1.4 2017/03/02 16:03:05IST Taherali, Khuzema (ktaherali) Exp $
$Id: si_co.dita 1.4 2017/03/02 16:03:05IST Taherali, Khuzema (ktaherali) Exp $
$Locker: $
$Log: si_co.dita $
Revision 1.4 2017/03/02 16:03:05IST Taherali, Khuzema (ktaherali)
Removed \u201c and \u201d and replaced wtih open and closed quotes (" and ")
Revision 1.2 2015/11/30 23:50:32IST Warner, Carrie (cwarner)
XML tagging fixes
Revision 1.1 2015/10/29 10:24:48EDT Flett, David (dflett)
Initial revision
Member added to project /rd/doc/Strategic/xmldocs/en/int-man_pages/si_ref/project.pj
$Revision: 1.4 $
$Name: $
$ProjectLabel: $
$ProjectName: /rd/doc/Strategic/xmldocs/en/int-man_pages/si_ref/project.pj $
$ProjectSetting $
$ProjectRevision: Last Checkpoint: 1.1.1.836 $
$RCSfile: si_co.dita $
$Revision: 1.4 $
$SandboxSetting $
$Setting $
$Source: si_co.dita $
$State: Exp $

• -f

overwrites the working file if it has changed since it was last checked in. This is equivalent to specifying --overwriteChanged.

• --[no|confirm]overwriteChanged

controls whether to overwrite the working file if it has changed since it was last checked in.

--overwriteChanged means always do it

--nooverwriteChangedmeans never do it.

--confirmoverwriteChanged means always ask before doing it. When asked to confirm overwriting the working file, you have the option of specifying y, n or d. Specifying d displays the differences between the member's working file and the revision that is being checked out.

Specifying the --yes or --no options automatically answers y orn to the confirmation question, and also automatically answers y or n to all questions asked.

• --[no|confirm]overwriteDeferred

controls whether to overwrite the working file if there is a deferred drop or update revision operation on the member.

--overwriteDeferred means always do it.

--nooverwriteDeferred means never do it.

--confirmoverwriteDeferred means always ask before doing it. When asked to confirm overwriting the working file, you have the option of specifying y, n or d. Specifying d displays the differences between the member's working file and the revision that is being checked out.

Specifying the --yes or --no options automatically answers y or n to the confirmation question, and also automatically answers y or n to all questions asked.

• --[no]restoreTimestamp

controls whether to restore the timestamp of the working file to the timestamp of the revision in the member history. If this is not specified, the timestamp is set to the current date and time.

• --[no|confirm]retainbinaryfiles

controls whether a confirmation message appears while checking out a modified binary file.

--retainbinaryfiles the modified binary file is checked out, without any confirmation message.

--[no]retainbinaryfiles the modified binary file is not checked out, without any confirmation message.

--[confirm]retainbinaryfiles a confirmation message appears, asking if you want to retain the changes to the modified binary file.

• sandbox member...

identifies a specific member; use spaces to specify more than one member.

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.