Check In

This topic describes the Check In dialog box, which appears when you select the Check in command. It is used for checking files into DesignSync.

unlock Leave behind Locked copies Links to cache Allow checkin of new items Recursive optionThis topic discusses the Recursive option available for some of the DesignSync commands. Force check in Perform dry run Record href versions Exclude optionThis topic explains the exclude option available for some of the DesignSync commands. DesignSync Exclude List PreferencesThis dialog box contains controls for exluding objects from DesignSync operations. Filter optionThis topic explains the filter option available from some DesignSync commands. Module Context optionThis topic discusses the Module context option available for some of the DesignSync commands. Report mode Href Filter optionThis topic discusses the Href Filter option available for some of the DesignSync commands. Comment OptionThis topic explains the comment option available for some DesignSync commands. Command InvocationThis topic discusses the Command invocation option available for some of the DesignSync commands. Command ButtonsThese buttons appear on many of the dialogs boxes. Not all buttons appear on all dialog boxes.
Retain TimestampThis topic discusses the Retain timestamp option available for some of the DesignSync commands. Allow version skipping Only process locked objects Tag Branch Keys optionThis topic discusses the Keys option available for some of the DesignSync commands. Trigger optionsThis topic discusses the Trigger option available for some of the DesignSync commands. Command InvocationThis topic discusses the Command invocation option available for some of the DesignSync commands. Command ButtonsThese buttons appear on many of the dialogs boxes. Not all buttons appear on all dialog boxes.

General tab

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.

Note: You can control whether these files are left in a read-only state or a writable state by using the Unlocked files are checked out in Read Only mode option on the General panel in SyncAdmin.

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

Note: Selecting this option also lets you check an object onto a retired branch. The branch is unretired and a new version of the object is created.

If the unmanaged object is being added to a module, then either a Module Context option must be specified, or there must be only one module in the workspace (so that DesignSync can determine the module context). 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.

Note: You cannot check in unmanaged objects to a new module branch. If you use the Branch option to specify a module branch, you must first Add the module members to the module.

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.

Note: When checking in module data, you cannot specify the Recursive option or the Branch option with the Allow check in of new items option.

By default, By default, this option is unselected. This option is mutually exclusive with the Only process locked objects option.

Recursive
See Recursive 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.

Note: You must have a local copy of the file in your working folder for a new version to be created. A new version is not created if the object does not exist or is a reference.

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.

By default, By default, this option is unselected.

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.

If you do not want to have the href versions captured as part of the check-in, then de-select this option.

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.

Exclude
See Exclude option.

The default for this option is blank.

Filter
See Filter option.

The default for this option is blank.

Module context
See Module Context option.

The default for this option is blank.

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
  • nformational 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.
This is the default report mode.
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.
Href filter
See Href Filter option.
Comment
See Comment Option.

Advanced

Retain Timestamp
See Retain Timestamp.
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.

Notes:

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

Note: The Branch field accepts a branch tag, a version tag, a single auto-branch selector tag, or a branch numeric. It does not accept a selector or selector list.

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.

Note: The module member version in the workspace is always considered the desired version for the ci -branch operation. If you have older member versions in the workspace, those will become the Latest version on the new branch.

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 check in of new items.

Keys
See Keys option.
Trigger arguments
See Trigger options.

Other

These sections appear on most dialog boxes

Command invocation
See Command Invocation.
Command buttons
See Command Buttons.