si resync

CLI Reference > Configuration Management Commands > si resync

si resync

updates a Sandbox with the member revision

Synopsis

Description

si resync compares the contents of project members with their corresponding working files in the Sandbox and replaces the working file with an exact copy of the member revision, if differences are detected or if no working file exists. If the working file is writable, you are optionally prompted for confirmation before it is replaced. This command has no effect on working files that are identical to the member revision.

The following is an example of the command syntax:

si resync c:/Aurora_Program/bin/Libra/project.pj

This command overwrites files, even ones that you have locked and that have changed since you last checked them out. Be certain of your response to any prompts indicating that the files will be overwritten - once replaced, you cannot get back your changes. If files have been dropped from a project, resynchronizing deletes them.

If the revision that your working file is based on is locked by you, your lock is automatically moved to the member revision before the resync proceeds. If another user already has an exclusive lock on the member revision, you are prompted to downgrade your lock to non-exclusive.

If you are working in a sparse Sandbox, resynching deletes your working file, unless the revision that it is based on is locked by you.

When working in your Sandbox, you can use the resynchronize by change package option.

The Resync By Change Package Option

The Resync by CP (--[no]byCP) option is primarily a tool for developers. When you want to resynchronize files in your Sandbox, you usually do so by choosing individual files and then using si resync command. However, if the files you are resynchronizing have changes that are linked to other files, the standard resync operation would not include those related files. To resynchronize all related files, you would have to manually search for all the changes associated with the change package on the member you are resynchronizing.

The Resync by CP option automates this process by searching the change package specified on the member revision you are resynchronizing and then bringing the changes from the project to your Sandbox.

While the Resync CP option searches all files related to a selected change package, and all the change packages that may be associated with the related files, the Resync By CP option only processes the change packages associated with the member you are resynchronizing.

How Does the Resync By CP Option Work?

The functioning of Resync by CP is affected by the options you choose for si resynccp. For more information, see si resynccp.

When Should I Use the Resync By CP Option?

Developers should use Resync By CP when they want to ensure that they have all dependent changes associated with a member revision, even if these changes are contained in other files. For example, a developer needs to check out (locked) a file and modify it. The developer finds that other revisions have been checked in since the member was resynchronized in the Sandbox. Because the Sandbox is quite large and contains many unrelated changes, the developer does not want to perform a standard resynchronization. The Resync By CP option can be used in this situation.

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.

• Note:

• If the working file of the member you are resyncing has been modified, Integrity Lifecycle Manager asks you to confirm that you want to merge your modifications into the working file.

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

specifies how you want to merge changes from the working file in your Sandbox into the member revision.

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

--mergeType=cancel cancels the selected merge type.

--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=cancel cancels the merge.

--onMergeConflict=mark marks the working file indicating that merging is required without completing all of the merge related tasks. This provides the time you may need to investigate conflicts or edit 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 ">>>>>>". You are responsible for resolving merge conflicts before checking in the changes.

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

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

• --[no]byCP

controls whether to cause Integrity Lifecycle Manager to operate in change package mode. Integrity Lifecycle Manager automatically searches the change package associated with the member and resynchronizes all member files contained in that change package.

If there are no revisions in the change package to resynchronize, a normal resync is performed.

• --[no]confirm

controls whether to proceed without confirmation messages when working with a change package (applies only when change packages are enabled).

• --[no]confirmPopulateSparse

controls whether to proceed without confirmation messages when populating a sparse Sandbox.

• --[no]includeDropped

controls whether to delete dropped members from your Sandbox.

• --[no|confirm]merge

controls whether to merge changes from the working file in your Sandbox into the member revision.

--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 it is being resynchronized with.

• 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.

• --[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:04IST $
$Header: si_resync.dita 1.5 2017/03/02 16:03:04IST Taherali, Khuzema (ktaherali) Exp $
$Id: si_resync.dita 1.5 2017/03/02 16:03:04IST Taherali, Khuzema (ktaherali) Exp $
$Locker: $
$Log: si_resync.dita $
Revision 1.5 2017/03/02 16:03:04IST Taherali, Khuzema (ktaherali)
Removed \u201c and \u201d and replaced wtih open and closed quotes (" and ")
Revision 1.2 2015/12/01 01:31:47IST Warner, Carrie (cwarner)
XML tagging fixes
Revision 1.1 2015/10/29 10:24:59EDT Flett, David (dflett)
Initial revision
Member added to project /rd/doc/Strategic/xmldocs/en/int-man_pages/si_ref/project.pj
$Revision: 1.5 $
$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_resync.dita $
$Revision: 1.5 $
$SandboxSetting $
$Setting $
$Source: si_resync.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 overwrite.

--nooverwriteChanged means never overwrite.

--confirmoverwriteChangedmeans always ask before overwriting. 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 it is being resynchronized with.

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|confirm]removeOutOfScope

controls whether to remove a current member's working file if it does not match the Sandbox scope definition, for example, if the scope definition or member changes (such as modified member attributes). Sandbox Scope defines what project members are included in the Sandbox, transferring specific members from the Integrity Lifecycle Manager Server to the Sandbox directory when the Sandbox is created and controlling what members display in the Sandbox view.

--removeOutOfScope means always remove the working file if it does not match the Sandbox scope.

--noremoveOutOfScope means never remove the working file if it does not match the Sandbox scope.

--confirmremoveOutOfScope means always ask before removing the working file if it does not match the Sandbox scope. When asked to confirm removing 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 member revision it is being reverted to.

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|confirm]overwriteIfPending

• controls whether to overwrite the working file if there is a pending operation on the revision corresponding to the working file.

--overwriteIfPending means always overwrite

--nooverwriteIfPendingmeans never overwrite

--confirmoverwriteIfPending means always ask before overwriting. 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 it is being resynchronized with.

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|confirm]overwriteDeferred

• controls whether to overwrite the working file if there is a deferred operation on the revision corresponding to the working file.

--overwriteDeferred means always overwrite

--nooverwriteDeferred means never overwrite

--confirmoverwriteDeferred means always ask before overwriting. 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 it is being resynchronized with.

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]overwriteUnchanged

controls whether to overwrite files that have not been modified in the Sandbox. This may be useful for forcing files to pick up new keyword expansions or timestamps even if their content has not changed.

• --[no]populate

controls whether to populate the Sandbox with a working file for the specified member. If you are working with a sparse Sandbox (see si createsandbox), specifying --populate with this command overrides the default sparse Sandbox behavior of removing working files.

• --[no]restoreTimestamp

controls whether to restore the timestamp of the working file to the timestamp of the revision in the member history.

• --[no|confirm]downgradeOnLockConflict

If the revision that your working file is based on is locked by you, your lock is automatically moved to the member revision before the resync proceeds. This option controls whether to downgrade your lock to non-exclusive if another user has an exclusive lock on the member revision.

--downgradeOnLockConflict means always downgrade

--nodowngradeOnLockConflict means never downgrade

--confirmdowngradeOnLockConflict means always ask before downgrading

• --[no]awaitServer

instructs the client to repeatedly attempt the operation if the Integrity Lifecycle Manager Server does not respond.

• current or dropped member/subproject...

identifies a specific member or subproject that currently exists in the project, or one that has been dropped from the project but still exists in the Sandbox. Use spaces to specify more than one. If you specify a dropped member or subproject, and if you specify --includeDropped, this command deletes the corresponding working file.

If you specify an out of scope member with no working file, the resync operation does not create a working file for the member. For more information on Sandbox scope, see thesi configuresandbox and si createsandbox commands.

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.