Check In | ||
| ||
Leave behind Unlocked copies
After the operation is over, keep an unlocked copy in your work area.
This is the default unless your project leader has defined a default fetch state. Because you have relinquished any lock you may have had on the file, someone else can check the file out from the vault with lock in order to modify it.
Leave behind Locked copies
After the operation is over, keep a locked copy in your work area. You can continue to work on the object. Others cannot check in new versions of the object as long as you have the branch locked. (The copy in your work area is known as an original.) This option is not available for legacy modules or legacy module configurations. When operating on modules, it is module members that are locked; not whole modules. Thus, this option is mutually exclusive with the Recursive option, or with a specified Module context.
For information on locking a module, see Locking an Object or Branch
Leave behind Links to cache
After the operation is over, keep a shared copy of the design object in a cache folder. This option is available only on UNIX platforms.
Leave behind Links to mirror
After the operation is over, keep a shared copy of the design object in a mirror folder. This option is available only on UNIX platforms. This option is not available for module data.
Allow checkin of new items
You must select this option if you are checking in an object that has never been checked in before or, in the case of module data, was neither checked in before, nor added to a module. When you check in the object, DesignSync creates a vault for it. This is the vault from which subsequent versions of the object are checked in and out. Once the vault has been created for the object, you do not need to select this option during checkins.
If the unmanaged object is being added to a module, then smart module detection is used to determine to which module the new objects should be added. If a module cannot be determined, you can use the Module Context Option to specify the module context. For information on smart module detection, see the ENOVIA Synchronicity DesignSync Data Manager User's Guide.
If a Module context is specified with a folder object, DesignSync performs the check in a module-centric way, checking in any unmanaged objects into the specified module. If the Recursive option is also specified, it is ignored and the hierarchical references are not followed.
If Allow version skipping is selected, and a module member has been removed between the currently fetched module version and the Latest module version, then specifying to Allow check in of new items will cause the removed member object to be added back to the module. The version of the member object that is added back into the module is the version that is currently in the workspace. If the version in the workspace has been modified, then a new version of the added back in member object is created.
For example, suppose you have version 1.4 of the Chip module, and version 1.3 of the module member file tmp.txt. The Latest version of Chip is 1.6. Version 1.6 of the Chip module does not contain tmp.txt, because tmp.txt was removed from the module. Using Allow version skipping with Allow check in of new items will add the tmp.txt object back into the module, in the module version 1.7 created with your checkin. You could also add the tmp.txt object back into the module by adding the tmp.txt object, then checking in with Allow version skipping, without having to Allow check in of new items.
By default, By default, this option is unselected. This option is mutually exclusive with the Only process locked objects option.
Force check in
If you check out a file, make no changes to it, and then attempt to check it in, DesignSync informs you that it will not check the file in. If you want to check the file in anyway, you must select this check box. The file will be checked in and a new version created that is identical to the version already in the vault.
In most cases, not being allowed to check in an unchanged file is reasonable. One reason you may wish to use this option is to keep version numbers synchronized.
By default, By default, this option is unselected.
Perform dry run
Select this option to indicate that DesignSync is to treat the operation as a trial run without actually checking in design objects. For module data, module hierarchy processing is included in the output.
This option helps detect whether there are problems that might prevent the checkin from succeeding. Because file and vault states are not changed, a successful dry run does not guarantee a successful checkin. Errors that can be detected without state changes, such as a vault or branch not existing, merge conflicts, or a branch being locked by another user, are reported. Errors such as permissions or access rights violations are not reported by a dry run. Note that a dry run checkin is significantly faster than a normal checkin.
Record href versions
When a module is checked in (either an entire module or any of its contents), DesignSync captures the currently populated versions of all of that module's hierarchically referenced sub-modules, and records those as part of the next module version. This is the default behavior, for the module version to reflect the contents of the workspace.
This option is ignored for non-module data.
If the Recursive Option is selected, and the check-in is operating in a Module context, then this option cannot be de-selected.
By default, this option is selected.
Report mode
For the Report mode, choose the level of information to be reported:
- Brief output
- Brief output mode reports the following information:
- Failure messages
- Warning messages
- Informational messages concerning the level of the hierarchy being processed.
- Success/failure status
- Normal output
- In addition to the information
reported in Brief mode, normal output mode reports:
- Informational messages for updated objects.
- Information about all objects processed.
- Verbose output
- In addition to
the information reported in Normal mode, verbose mode outputs:
- Informational message for every object examined but not updated.
- Information about all filtered objects.
- Errors and Warnings only
- Brief output mode reports the following information:
- Failure messages.
- Warning messages.
- Success/failure status.
Allow version skipping
By default, this option does not appear in the Check In dialog box. For the Allow version skipping option to appear, the option must be set in the Sync Administrator application.
This option allows you to create a new version, even if the new version is not derived from the Latest version. This happens if your modifications were to a non-Latest version. The new version skips over changes made in intermediate versions, which is why the option is hidden by default.
You typically need to specify Allow version skipping when you check into a branch other than the current branch of the data in your workspace, by using the Branch field.
For module data, the objects that are being considered for checkin may still be checked in if there is a later module version that has affected those objects. For example, suppose you have module version 1.4 of Chip, which contains version 1.2 of file.txt. You modify your local copy of file.txt. Meanwhile, a later version of the module Chip has been checked in, containing version 1.3 of file.txt. Opting to Allow version skipping will include your file.txt modifications in the new version of the module that is created, skipping over the changes in version 1.3 of file.txt. However, if a module member file was renamed or removed in intermediate module versions, then those structural changes are also skipped. Allow version skipping also applies to changes to hierarchical references. If the checkin is capturing a new static version of a submodule for an href, and an intermediate module version also changed the href, Allow version skipping will cause the href change in the workspace to be applied.
Only process locked objects
Performs a checkin that only includes targeted files. Changes that are checked in are:
- Locked DesignSync vault files or module members.
- Objects that have been added to a module.
- Module members that have been renamed or removed since the last module checkin.
By default, By default, this option is unselected. This option is mutually exclusive with the Allow checkin of new items option.
Tag
Tags the object version or module version on the server with the specified tag name.
For module objects, all objects are evaluated before the checkin begins. If the objects cannot be tagged, for example if the user does not have access to add a tag or because the tag exists and is immutable, the entire checkin fails.
For other DesignSync objects, if the user does not have access to add a tag, the object is checked in without a tag.
- If both a tag and a comment are specified for a module version or branch checkin, the comment is also used as the tag comment.
- You cannot tag modules stored on DesignSync server versions prior to 5.1.
Branch
Specify a branch in the Branch field to check in to a branch other than the one from which you checked the object out.
This field is not applicable to module data.
When branching a module, you must create a new branch. You cannot specify an existing branch. The module branch checkin creates the new module branch version with the following module member objects:
- Added objects that have not been checked in yet.
- Modified objects belonging to the specified module.
- Unmodified objects belonging to the specified module.
- Objects that are part of the module on the server, but have not been populated into the workspace.
- Objects in the workspace that were removed on the server in a later module version.
When you check a module into the new branch, DesignSync automatically modifies the workspace selector to the Latest version of the new branch tag (<Branch>:Latest).
The Branch option, when specified with a module, is mutually exclusive with Recursive Option and Allow checkin of new items.
Other
These sections appear on most dialog boxes
- Command invocation
- See Command Invocation.
- Command buttons
- See Command Buttons.