Use Check-In and Check-Out in CA Harvest SCM

This article lets you get started with check-in and check-out processes.
cahscm101
This article lets you get started with check-in and check-out processes.
2
Client Directories and View Paths
As you move about in the client directories or in the repositories, your path is defined by your current position in the hierarchy. A
view path
is a location in the
CA Harvest SCM
repository. The project and state you select define which view paths, items, and versions you can see.
Root Directory and Root View Path
CA Harvest SCM
uses the concept of a client root directory and a view path root to let you control how your client directory path and view path change. In the Find Version dialog and in the check-in and check-out process execution dialogs, you can set the client root directory or view path root to a certain location. This lets you synchronize the check-in and check-out processes with the client directory and view path structure already established.
Two distinct roots can be defined:
  • Client Root Directory
    when viewing files. By selecting your client root directory, you are setting a default client directory that is inserted in the client root directory field during subsequent check-in processes.
  • View Path Root
    for repository paths, when viewing items and versions. By selecting your view path root, you are setting a default view path that is inserted in the view path root field during subsequent check-out processes.
Internal and External Directory Structures
An administrator creates a repository and loads it with a set of directories and files that, typically, make up an application. The administrator duplicates an external application directory structure in the repository and in the baseline of any projects that use it. In the repository structure, the top-level is the repository name and the application directory paths lie beneath it.
Typically, individual developers maintain a client directory structure that is similar to the repository structure, and use it for updating application items and building the application for testing.
Example: Load a Client Directory Structure into the Repository
This illustration is an example of a client directory structure in an application named app1:
Illustration showing loading of a client directory structure into the repository
Illustration showing loading of a client directory structure into the repository
Example: Duplicate an Application Structure in the Repository
This example shows that when this application is loaded into a repository named repository-app1, the application structure is duplicated in the repository. When users access
CA Harvest SCM
to look at items in a view that includes this repository, the repository view paths look like the following illustration:
Duplicate an Application Structure in the Repository
Duplicate an Application Structure in the Repository
Example: Mirror the Application Structure on a Windows Client
Assume that you have been working on this application, and it has working directories on a Windows client mirroring the application structure. The following illustration shows what your client work area would look like:
Illustration showing mirrorring of the Application Structure on a Windows Client
Illustration showing mirrorring of the Application Structure on a Windows Client
Example: Synchronize the Directory Structure Using Roots
This example shows how roots synchronize the internal and external directory structure. In this case, the view path root is set to /repository-app1 and the client directory root is set to c:\workarea\app1. These two roots mark the point of synchronization between items inside the repository and their corresponding files on the client directory.
Synchronize the Directory Structure Using Roots
Synchronize the Directory Structure Using Roots
Browse for Agent Folder
You can browse for a remote agent folder on any connected agent from the check-out or check-in process dialog.
Follow these steps:
  1. Click the browse button for the check-out To field or check-in From field on their respective process dialogs.
    You can perform a check-out or check-in from your local file system or from a remote agent. When you select the Browse for agent option, a dialog appears, which lets you locate and select a remote agent.
  2. Expand the agent node you want to browse.
    If an agent node is disabled in the tree, the agent is unreachable from the broker and cannot be used to select a remote folder.
  3. Expand the agent tree and selected your folder you want. Click OK.
    The Browse For Folder dialog closes and your selection populates the check-out or check-in process dialog field.
File Permissions
CA Harvest SCM
assumes a long-term relationship between a set of user working directories and a repository structure. In these working directories,
CA Harvest SCM
uses file permissions to indicate files not available for update. File permissions are altered during check-out and check-in.
Because permissions are managed according to the state of corresponding items in
CA Harvest SCM
, we recommend that users do not alter file permissions. Altering file permissions could lead to unexpected results during check-out or check-in.
File permissions are handled differently depending on the client's operating system. For example, UNIX and Linux make greater use of file permissions than Windows operating systems. On Windows operating systems,
CA Harvest SCM
uses only one level of access permission, represented by the read-only attribute.
  • On Windows client systems, checking out a file in browse or synchronize mode creates a file on the client file system marked as read-only. This indicates that the file cannot be modified and checked in because these modes do not create a reserved version in
    CA Harvest SCM
    . When checking out for update or concurrent update, the file is given normal (write access) file status.
  • On UNIX and Linux, when a file is checked in to
    CA Harvest SCM
    , information about file permissions is maintained in the
    CA Harvest SCM
    database. When the corresponding item is checked out for update, the same file permissions are set on the client file, with one exception. Any time a user checks out an item for update, write access is granted so that changes can be made to the file.
    For example, consider a UNIX or Linux file with the following permissions:
    r-xrwxrwx
    When this file is checked in to
    CA Harvest SCM
    , the file permissions are stored. Upon check-out for update, the permissions are:
    rwxrwxrwx
    When a file is checked out for browse,
    CA Harvest SCM
    does not use the exact information stored with the file. It places the file in the directory without write permission for user, group, and other. The permissions now look like this:
    r-xr-xr-x
Display File Type Attributes (Binary/Text)
You can display file type attributes (binary or text) in the following ways:
  • Click a file version in the Explorer View.
    The file type displays as an entry in the Stored As column of the Lists View.
  • Right-click a file version, and select Properties from the shortcut menu.
    The file type displays in the Stored As field in the Properties View.
File and Item Case-Sensitivity
CA Harvest SCM
check-in and check-out behavior differs among UNIX, Linux, and Windows operating systems because of the case-sensitive behavior of file systems on these operating systems. For example, the file File.c is not the same as FILE.C on a UNIX or Linux operating system, but it is the same for a Windows or z/OS operating system.
Case-sensitivity depends on the operating system of the file agent. If you are not using a remote file agent, your client program acts as the file agent.
  • If you check in and check out files locally (not with a remote file agent), case-sensitivity depends on the local operating system (where the client program is running).
  • If you check in and check out files remotely (with a remote file agent), case-sensitivity depends on the remote operating system (where the file agent is running).
With UNIX or Linux file agents,
CA Harvest SCM
is case-sensitive for file and item names. If you check out the item file.c using a UNIX or Linux file agent, you must check in the file with this name; if you change the case of the name to FILE.C on the file system prior to check-in, it is checked in to the repository as a new item.
With Windows file agents,
CA Harvest SCM
is not case-sensitive. If you check out the item File.c using a Windows file agent, you can successfully check in this item as FILE.C, file.c, or as any other case.
Signature Files
Checking in or checking out an item automatically updates information in a signature file maintained by
CA Harvest SCM
in each directory containing Change Manager (CM)-related files. To update or create the signature file, you must have write access to the directory from which you are checking in items.
For more information about signature files, see the
Reference section
.
After checking in a file from a read-only device (for example, a CD-ROM), the
CA Harvest SCM
output log shows error message E02020053 and informational message I00020100. These messages display that the signature file was not opened but the file was checked in. Error message E02020053 correctly reports that the check-in process was unable to create a signature file on the read-only device. The signature file cannot be created because the read-only device is not writable. Informational message I00020100 correctly reports that the check-in process was successful.
For more information about the messages, see the
Messages section
.
Partitioned Data Sets
You can check in and check out the following:
  • Partitioned data set (PDS)
  • Partitioned data set/extended (PDS/E)
  • All other Data Control Block (DCB) for PDSs
    PDSs with an undefined record format are not supported. All other Data Control Block (DCB) for PDSs are supported.
CA Harvest SCM
does not list migrated data sets. To check in from migrated data sets or check-out to migrated data sets, you must first recall the data sets using the appropriate commands for your system (for example, HRECALL, RESTORE, DRESTORE, $RA, and so on).
You
cannot
check in and check out the following:
  • Sequential data sets
    To check in sequential data sets, copy the sequential data sets to a PDS or PDS/E, and then check in the PDS or PDS/E.
  • Load libraries
  • Variable Blocked (VB) data sets in binary mode
When checking out a PDS, the check-out dialog dynamically changes after selecting a PDS to populate the To field. The dialog adds an additional option, Remove MVS extension. The Remove MVS extension removes the last-level qualifier from the selected data set. This option works with the To field. If an item has an extension and is checked out to a PDS, the item name is the PDS member name and the extension is added to the data set as the last-level qualifier. If the data sets already exist with the appropriate last-level qualifier, select the Remove MVS extension option prior to check-out. The To field destination name reflects the removal.
The agent applies the item extension to the last-level qualifier at check-out. This option lets you check out multiple items with different extensions to multiple files on a single check-out. If the PDS member does not exist, it is created at check-out. The PDS must exist prior to check-out.
z/OS File Conversion
The z/OS agent translates text files to a unified format at check-in and translates text files to the z/OS format on check-out. Files are read in and written out using stream input/output.
For Hierarchical File System (HFS) files,
CA Harvest SCM
translates from Extended Binary-Coded Decimal Interchange Code (EBCDIC) to ASCII and performs stream input/output as defined in the
z/OS C/C++ Programming Guide
.
The z/OS agent explicitly performs ASCII to EBCDIC translation. The ASCII code page is set to ASCII code page 437. The EBCDIC code page is set to EBCDIC 037.
To avoid compilation errors on C++ and JAVA text files, the z/OS agent translates the following characters to EBCDIC 1047 code page format: “ [“,”]”, and “ ^”. This means that text files containing these characters are always checked out using the 1047 code page format as shown in the following hexadecimal character table. Files containing EBCDIC hexadecimal characters BA, BB, or B0 are always checked out with EBCDIC hexadecimal characters BD, AD, 5F, respectively.
 
ASCII HEXADECIMAL
EBCDIC 037 HEXADECIMAL
EBCDIC 1047 HEXADECIMAL
[
5B
BA
BD
]
5D
BB
AD
¬
AA
B0
5F
 
Check-Out Process
The check-out process lets you copy versions of items under
CA Harvest SCM
management to external directories where you can update or browse the items. Alternatively, you can reserve the items without copying the data to a client directory. The reserved version placeholder created by the check-out is associated with the package you select.
When you select a tagged version for check-out,
CA Harvest SCM
automatically eliminates that version from your check-out selection and it does not populate the check-out list. For example, if you select three versions including one that has a reserve tag, and select check-out, only the two untagged versions populate the check-out list.
If you select a folder, it must contain at least one version or the check-out cannot continue. In the case of recursive check-out, the selected folder or its subfolders must contain at least one version or the check-out cannot continue. In both cases, an error message displays.
You can check out an item to a remote location. Access to data files in remote locations requires WRITE permission based on the registered user name and password for the remote computer.
Check-Out Rules
The following rules govern the check-out process:
  • Access
    -- To check out an item for browse or synchronize, you need at least view access to the item. To check out an item for update or concurrent update, or to reserve an item, you need edit access to the item.
  • Duplicates
    -- You can check out any version of an item, not only the latest. You can check out only one version of an item at a time to the same directory on the file system.
  • Package
    -- A package in the current state is required to check out an item for update, concurrent update, or reserve only. A package can only create one reserved version per item, either on a branch or on the trunk.
  • Version
    -- The only trunk version that you can check out for update is the latest. You can only check out a trunk version for update if it is not reserved by another package. This version is available for updating even if it does not yet appear in the current view. To check out an earlier trunk version for updating, you must use the concurrent update mode.
  • Updating a Branch
    -- To check out and modify a branch version, you can use the update or concurrent update mode of check-out. Both create a reserved branch version that is replaced when the file is checked in. The package specified for the check-out must be the same as the package that created the branch.
  • Unmerged Branches
    -- A package can only have one unmerged branch version per item. A second attempt to check out an item for concurrent update fails if an existing unmerged branch is found for that item with that package. The current branch version should be either merged or deleted before attempting to use the concurrent update mode of check-out again for the same item with the package.
  • Tagged Versions
    -- Versions tagged as merged (M) or removed (D) cannot be checked out. A reserved version (R) can be checked out only for browse mode; its content is the same as the previous version.
Check-Out Paths
The From and To check-out paths work together to help you synchronize the internal (repository) and external (file system) structures. You typically use the From and To paths to establish a point at which paths in the repository mirror working directories on the client.
The view path displayed in this field is determined in one of the following ways:
  • If you use the Find Version dialog to select versions, the most common path in the version list populates this field. When your list changes, the field is updated to display the most common path.
  • If you select a View folder or an item or version in a View folder, and execute the check-out process, the view path for the selected item is used.
  • When you select an item for check-out,
    CA Harvest SCM
    automatically selects the item's latest versions without tags to populate the check-out list. If the Versions list contains folders or versions outside the From view path (not a descendant of the view path), the check-out cannot continue. An error message cautions you about unexpected results.
File Date and Time
Although
CA Harvest SCM
stores the file modification date and time, the date and time associated with the file created when an item is checked out reflects the current date and time. This algorithm supports building an application by ensuring that the source files are more recent than object files.
Replace Read-Only Files Option
The Replace read-only files option controls whether the checked-out files should replace existing read-only files on the file system. This option lets you replace files that you previously checked out as read-only or checked in. If a corresponding file does not exist on the file system, the item is checked out regardless of the value for this option.
Files that are not read-only on the Windows file system, or that have write permission on the UNIX or Linux file system, are never overwritten.
CA Harvest SCM
assumes that such a file has been checked out for update and not checked in yet. Overwriting such a file can cause you to lose unsaved changes.
On UNIX and Linux, file ownership affects the results of the read-only files option. When used alone, the Replace Read-Only Files option overwrites read-only files only if the user executing the check-out is the owner of the files being replaced.
Check Out Versions
The check-out process dialog lets you copy versions of items under
CA Harvest SCM
management to external directories.
Follow these steps:
  1. Navigate the Workbench to the package you want to use to check out versions.
  2. Right-click the package, and select
    check-out process
    from the shortcut menu.
    The
    check-out
    process
    dialog appears.
    The lowercase
    italic
    text indicates the process dialog name by the process type, since the process execution dialog names differ to each site.
  3. Select a Mode option:
    • Update
      Copies selected versions to the destination client directory and creates a reserved version on each item's trunk, letting you check in the corresponding files. The permission on a read-only file is changed to normal (write access) when you use this mode of check-out.
    • Browse
      Copies the items to the destination directory but does not let you check in the files. The read-only attribute is set on files that are checked out for browse mode.
    • Synchronize
      Identifies the versions of the files in the client file system by using the signature file. Versions are checked out only if the signature file shows:
      • Client files that differ from their corresponding
        CA Harvest SCM
        versions.
      • Client files with timestamps that differ from their corresponding timestamps in the signature file.
      Items are checked out in a read-only mode.
      The check-out for synchronize mode is useful in the build process. This option compares the version on the file system with the version in the database. If the database version contains a newer timestamp, the file is checked out.
    • Concurrent Update
      Copies selected versions to the destination client directory and creates a reserved version on a branch for each item. All updates accumulate on this branch. The permission on a read-only file is changed to normal (write access) when you use this mode of check-out.
    • Reserve Only
      Creates a reserved version with a reserved tag (R) on each item's trunk. You can check in corresponding files, but cannot move any data to external directories.
  4. Select an option to specify the way for checking out items to client paths:
    • Preserve View Path and Structure
      Checks out all selected items to corresponding client directories, if they exist. If the directories do not exist, an error message displays and the items are not checked out.
      If you select a single file for check-out, the checkout is successful; in spite of the path not matching with the new view path.
    • Preserve and Create Directory Structure
      Checks out all selected items to corresponding client directories and creates any client directories that do not currently exist.
    • All Files to the Same Client Directory
      Places all selected items directly beneath the specified client directory, ignoring the path structure in the repository.
    The options work with the Include subfolders option on the Find Version dialog.
  5. Specify a view path in the repository from which items are checked out in the From field.
  6. Specify the destination on the file system for the checked-out files in the To field.
    • If either of the preserve structure check-out options is selected, the check-out specifies a path and this specification is appended to the file system directory.
    • If the files being checked out include a directory specification, as in a recursive check-out, this directory specification is appended to the client path specified.
    • Agent
      Displays the remote computer name if the client path is on a remote computer.
    • Add Remote Agent Connection
      Lets you add the new remote agent connection whose values populate in the Agent name and To fields.
      For more information about adding a remote agent connection, see the Connect to a Remote Agent section.
When you connect to multiple agents on the same computer and check-out from the Workbench,
CA Harvest SCM
identifies the agent with a unique combination of agent name, port number, and the initial directory. This selection auto populates the To field with the initial directory of the agent computer.
  1. Select versions to check out:
    • Snapshot
      Specifies a snapshot from which you can select versions to check out. This field is enabled when a snapshot exists in the view in which you are executing the check-out process.
      You can select versions from the snapshot and can return them to the check-out process execution dialog.
    • Versions
      Lists the versions that you have selected for check-out. If you have selected a version before selecting the check-out process, the version appears in the list. If you have not selected a version before invoking the check-out process, you can add more than one version by clicking the Select Version.
  2. (Optional) Select check-out options:
    • Replace read-only files
      Controls whether the checked-out files must replace existing read-only files on the file system.
    • Recursive
      Selects all versions in the selected folders
      and
      subfolders in the Versions list. The versions in the subfolders are checked out
      only
      if you select this option.
      This check box is disabled if no folders are selected.
    • Create empty directories
      Creates directories that contain no items during a recursive check-out. This option works with the Include subfolders option in the Find Version dialog.
    • Include versions from package
      Selects the latest versions from the trunk and branch that are associated with the package context.
  3. (Optional) Click Note to view information about the process.
  4. Click OK.
    The versions are checked out.
Repository Cache Use on a Remote Site
If your network access to the
CA Harvest SCM
server is relatively slow (for example, on a WAN or using VPN), your check-out performance may degrade when performing large recursive check-outs. You can use the optional Repository Cache on Remote Site function in these circumstances to improve your check-out performance. Repository Cache stores version data files locally, accessed using a
CA Harvest SCM
remote agent or directly in a local directory.
For details about Repository Cache on Remote Site, see the
Administrating section
.
Check-In Process
The check-in process lets you copy files from the client directory system to
CA Harvest SCM
, creating items or updating existing items that have changed. To check in an existing item, it must be reserved by a package. If the item was originally checked out for concurrent update, the check-in process updates the current package's branch. If the item was checked out for update or reserve only, the check-in process updates the trunk for the item.
You can check in files from remote locations. For example, you can check in files on an AIX operating environment to a
CA Harvest SCM
repository managed by a server process that runs on a Solaris operating environment where the file cannot be accessed through NFS. Access to data files in remote locations requires a user name and password for the remote computer.
Check-In New Item and Item Path Rules
The following rules apply to the check-in of new items and item paths:
  • When you check in a new item or item path to the trunk, it is version 0.
    This is the same version designation as items added to a project when you use the configure baseline function.
  • When you check in a new item or item path to the branch, it is version x.1.1. When you merge this branch version to the trunk, the version becomes a normal version that is version 0.
  • An item can be checked in to a branch using more than one package. In this case, the second version becomes x.2.1, the third x.3.1, and so on. This is the same convention as when you check out the same item in different packages; the only difference is the x. designation.
  • When you check in a new item or item path to a view path, it is version 0 or if it is a branch version, x.1.1. If you check in the same item or item path to a different view path in the same project, it is version 0, or if it is a branch version, x.1.1.
  • You can check in only one new item path to a branch per project. This means that you cannot create the same item path using a different package, nor can you rename an item path to that new path name. You can check in new items to the new item path in the same package.
  • You can check in the same item name with the same item path in more than one package when you check in the item to a branch. You cannot check it in to the same package more than once.
  • If you check in and create items and item paths to the trunk using the Preserve and Create Path Structure option, the item paths are immediately visible in all working views of the project. The items are initially visible only in the working view to which they were checked in.
  • If you check in and create items and item paths to the branch, neither the items nor the item paths are visible in the data view until they are merged to the trunk. However, you can use a package's versions list or set the package perspective to show the branch versions, for example, by clicking the Versions node of the package.
Check-In Client Path
The check-in client path is determined in one of the following ways:
  • If you use the Find File dialog to select files, the most common path in the file list populates this field. When your file list changes, the field is updated to display the most common path.
  • If you select a file in the WorkAreas view and execute the check-in process, that context is used in the check-in dialog.
Check In Files
The check-in process lets you copy files from the client directory system to
CA Harvest SCM
, creating items and item paths or updating existing items that have changed.
Follow these steps:
  1. Navigate the Workbench to the state in which you want to check in files.
  2. Right-click the state, and select
    check-in
    process
    from the shortcut menu.
    The
    check-in
    process
    dialog appears.
    The lowercase
    italic
    text indicates the process dialog name by the process type, since the process execution dialog names differ to each site.
  3. Select a mode:
    • Update and Release
      Checks in the file to the repository and the reserved tag is removed from the corresponding item. The permission on the client file is automatically set to read-only so that changes cannot be made to it until it is checked out again.
    • Update and Keep
      Updates the item in the view, the current package keeps it reserved and the file permissions unchanged so that you can make more updates.
    • Release Only
      Does not check in or update the item and the item is no longer marked as reserved for the current package. The permission on the client file is automatically set to read-only so that the file cannot be changed until it is checked out again.
      Release Only does not require the local file system file to exist.
      Selecting Release Only mode implies an item filter of Existing Items Only because this operation requires existing reserved items in the repository.
  4. Click the button next to the Package field to open the Select a Package dialog.
    The Select a Package dialog appears.
  5. Select a package to associate with updates to an item, and click OK.
    Your package selection appears in the Package field.
  6. Establish a point at which paths in the repository mirror working directories on the client:
    • From
      Specifies the client file directory. You can click the button next to this field to open the Browse For Folder dialog that lets you browse through available paths, and select a location.
    • Machine
      Displays the remote computer name if the client path is on a remote computer.
    • To
      Specifies the path location in the destination view to check in files. To change the path, click the button next to this field to open the Repository Path Selection dialog that lets you browse through available paths, and select a location.
      If the files being checked in include a directory specification, as is the case during recursive check-in, this directory specification is appended to the view path specified here when you specify a preserve structure check-in option.
    The internal (repository) and external (file system) structures are synchronized.
  7. Specify the way to check in files to view paths:
    • Preserve Directory Structure
      Checks in the selected files to repository view paths with names that correspond to their client directory location if these view paths currently exist.
    • Preserve and Create Path Structure
      Checks in selected files to paths with names that correspond to their client directory location and creates any view paths that do not currently exist.
    • All Files to Same View Path
      Checks in all selected files to the same path in the destination view and ignores the client directory structure.
    The way you check in the files to view paths is set.
  8. Specify how to filter the files being checked in:
    • New or Existing Items
      Checks in files if they are reserved by the package or did not previously exist in the repository. A corresponding item does not need to exist in the current view; however, if it is in the current view, it must have a reserved version in the current package.
    • New Items Only
      Limits the check-in to files that do not have corresponding items in the current view. If the item has been removed from the current view, you can check in the file using this filter.
      If the corresponding item was renamed in the current project, you cannot check in the file. You must rename the file before you can check it in.
    • Existing Items Only
      Limits the check-in to files that have corresponding items reserved by the package. Any files without corresponding items are skipped. This filter helps prevent the existence of unwanted files, such as temporary files or templates, in your repository.
    The check-in filter is set.
  9. Select a Placement option:
    • Trunk
      Creates versions on the trunk.
    • Branch
      Creates versions on a branch.
    The location of the checked-in versions is set.
  10. Specify files to check in.
    If you select files in the client directory before invoking the process dialog, the files populate the Files field. You can also select files by clicking Add (the plus [+] sign) to open and use the Find File dialog.
  11. Select options, and enter and view information about the check-in:
    • Delete files after check in
      Deletes from the client file system all files successfully checked in with the mode Update and Release, or Release Only. Deleted files are also removed from the signature file (harvest.sig) on the client.
  12. (Optional) Click the tabs to enter and view information:
    • Comment
      Specifies comments.
    • Note
      Provides notes about the process.
      If the Enforce Change Description option is selected in the check-in Properties dialog, you cannot execute a check-in successfully without entering a description.
    Click OK.
    The files are checked in.
Drag-and-Drop and the Files List
You can populate the Files list of the check-in process dialog using any of the following methods:
  • Selecting one or more files or directories from Windows Explorer and dragging them to the Files list.
  • Selecting files from multiple source directories by performing multiple drag-and-drop operations from different source locations.
  • Selecting an entire directory and its subdirectories (recursively) to be added to the list of files to be checked in.
When dragging files from multiple directories, the client path is updated each time the files are dropped into the Files list. With each new drag-and-drop, the client path is updated and the Files list is appended. The check-in process uses the path set by the last drag-and-drop operation for the check-in client path.
Check In Reserved Versions
The package check-in lets you check in reserved versions but does not let you specify the view path or client path. The paths you used during check-out are retained and used for the package check-in. For example, you could associate various versions from different view paths with one package and then check out the package to your client directory. If you update the versions, executing a package check-in places the changed versions in their original view path locations.
Follow these steps:
  1. Navigate the Workbench to the package that has the reserved versions you want to check in.
  2. Right-click the package, and select
    check-in
    process
    from the shortcut menu.
    The
    check-in
    process
    dialog appears and displays the versions associated with the package.
    The lowercase
    italic
    text indicates the process dialog name by the process type, since the process execution dialog names differ to each site.
  3. Select a mode:
    • Update and Release
      Checks in the version to the repository and the reserved tag is removed from the item. The permission on the client file is automatically set to read-only so that changes cannot be made to it until it is checked out again.
    • Update and Keep
      Updates the item in the view, the current package keeps it reserved and the file permissions unchanged, so that you can make more updates.
    • Release Only
      Does not check in or update the item, and the item is no longer marked as reserved for the current package. The permission on the client file is automatically set to read-only so that the file cannot be changed until it is checked out again.
      This mode does not require the local file system file to exist. If the file does not exist on the local file system, right-click the reserved version, and select the check-in process.
      Selecting Release Only mode implies an item filter of Existing Items Only because this operation requires existing reserved items in the repository.
  4. (Optional) Click the tabs to enter and view information:
    • Comment
      Specifies comments.
    • Note
      Provides notes about the process.
    Click OK.
    The reserved versions are checked in.
Use -ciignorehostname to Check In Reserved Versions
To perform a version-based check in of all your files from the local computer irrespective of where you checked them out, specify the -ciignorehostname option in HClient.arg. Restart the client for the new settings to take effect.
When you specify the -ciignorehostname option, the version-based check in from the remote agent is disabled. Therefore, use the file-based check in to check in from the remote agent.
For more information about HClient.arg, see the
Installing section
.
How to Fix Errors During Check-In and Check-Out
For the check-in and check-out processes only, you can view errors in the Log View and in a separate Error List dialog. The Error List automatically opens during the check-in and check-out process execution if fatal errors occur.
After viewing any errors on the Error List dialog, do the following:
  1. Return to the check-in or check-out process dialog without closing the Error List.
  2. Fix the errors.
  3. Execute the check-in or check-out process again, without closing the process execution dialog and without checking the Log View.
  4. Close the Error List.