hrefresh Command

The hrefresh command works with hsync to synchronize a file system directory with the contents of a path in a view (working or snapshot).
cahscm101
The hrefresh command works with hsync to synchronize a file system directory with the contents of a path in a
CA Harvest SCM
view (working or snapshot).
Server UDPs, which may be post-linked to any
CA Harvest SCM
process that updates the contents of data views such as promote and demote processes, execute the hrefresh command. The post-link command provides hrefresh with the project, state, and package context information. The hrefresh command uses this information to determine which reference directories should be refreshed for that particular transaction. The hrefresh command then uses hsync to synchronize the files on servers that are defined as reference computers.
At execution time, hrefresh reads a configuration file and selects configuration records that apply to its argument list. For each reference computer record that matches the records in the list, hrefresh asynchronously executes a series of commands, including pre-commands and post commands listed in the configuration file. The hsync command executes after the pre-commands and the post commands follows it. The hrefresh command stores the results of all command executions in a log file located in the hrefresh directory.
A stand-alone server UDP can also execute hrefresh, supporting on-demand directory synchronization.
2
How hrefresh Selects Items
Based on the input that hrefresh receives from the
CA Harvest SCM
UDP, hrefresh determines which inventory option to use in the following sequence:
  1. Item list
    --
    The hrefresh command checks the input list for the [version] variable. The inventory is all items in the view of the specified state and specified view path. The inventory is equivalent to using the -il option.
  2. Package list -- The hrefresh command checks the input list for the [package] variable. The inventory is all items that have versions in the list of packages and the specified view path. The inventory is equivalent to using the -pl option.
  3. Full view -- The hrefresh command checks the input list for the [version] and [package] variables; if neither is found, the inventory is all items in the view of the specified state and view path. The inventory is equivalent to using the -iv option.
hrefresh Post-Linked to Processes Use Cases
In the following use cases, hrefresh is a post-linked user-defined process (UDP) to processes in the MERGE and INTEGRATION BUILD states of a project. Both states use the default option, -to (trunk only). In the MERGE state, RDSU is configured for an Active reference directory type. In the Integration Build state, RDSU is configured for a Full reference directory type. The following diagram illustrates this scenario:
hrefresh Post-Linked to Processes Use Cases
hrefresh Post-Linked to Processes Use Cases
Use Case: Remove Path
This use case presents synchronization of the items impacted by a remove path process.
  1. An hrefresh UDP that is post-linked to a remove path process in the MERGE state executes hsync.
    The remove path process supports the package system variable, so the - pl option invokes hsync.
  2. The package contains all the D-tag versions that the remove path process created. These versions include a version of the removed path, plus a version of every item and path below the removed path. The package can contain other items. Because hsync does not know which items in the package must be synchronized, it synchronizes all.
  3. All those items disappear from the state item view, so no version of those items are checked-out.
  4. For every removed item below the Src view path, if hsync finds a file under /Build/Merge/Src corresponding to a previously checked-out version of the item, hsync deletes the file.
  5. If the directories corresponding to removed paths are empty except for signature files, the directories are also deleted.
Use Case: Rename Path
This use case presents synchronization of the items impacted by a rename path process.
  1. An hrefresh UDP that is post-linked to a rename path process in the MERGE state executes hsync.
    The rename path process supports the package system variable, so hsync is invoked with the - pl option.
  2. The package contains all the versions that the rename path process created. These versions include a version of the renamed path, plus a version of every item and path below the renamed path.
  3. Hsync deletes files under /Build/Merge/Src corresponding to previously checked-out older versions of the same items. If the directories corresponding to older path versions are empty except for signature files, the directories are also deleted.
  4. If the path that was renamed is below the Src view path, hsync checks out all the new versions to a subdirectory with the new name below /Build/Merge/Src.
    Refactoring of the top-level view path is not supported. The name of the path is in the hrefresh configuration file. If the path is renamed in
    CA Harvest SCM
    , you must change the name manually in the configuration file. The view path name passed to hsync must be consistent with the latest version of a path in view.
Use Case: Move Item
This use case presents synchronization of the items impacted by a move item process.
  1. An hrefresh UDP that is post-linked to a move item process in the MERGE state executes hsync.
    The move item process supports the package system variable, so the - pl option invokes hsync.
  2. The package contains the version that the move item process created.
  3. If hsync finds a file under /Build/Merge/Src corresponding to a previously checked-out older version of the item in its previous path, hsync deletes the file.
  4. If the new path of the item is below the Src view path, hsync checks out the new version of the item using the Preserve and Create Directory Structure option to the same relative path below /Build/Merge/Src.
Use Case: Move Path
This use case presents synchronization of the items impacted by a move path process.
  1. An hrefresh UDP that is post-linked to a move path process in the MERGE state executes hsync.
    The move path process supports the package system variable, so the - pl option invokes hsync.
  2. The package contains all the versions created by the move path process. These versions include a version of the moved path, plus a version of every item and path below the moved path.
  3. The hsync command deletes files under /Build/Merge/Src that correspond to previously checked-out older versions of the moved items. If the directories that correspond to moved paths are empty except for signature files, the directories are also deleted.
  4. If the new paths of the versions are below the Src view path, hsync checks out all the new versions to the same relative paths below /Build/Merge/Src.
Use Case: Check In Empty Directory
This use case presents synchronization of the items impacted by a check-in process.
  1. An hrefresh UDP that is post-linked to a check-in process in the MERGE state executes hsync.
    Check-in supports both the version and package system variables and the pathversion variable.
  2. A user checks in an empty directory.
  3. If the new path is under Src, hsync creates a subdirectory with the same relative name under /Build/Merge/Src.
Use Case: Delete Version of Moved Item
This use case presents synchronization of the items impacted by a delete version process.
  1. An hrefresh UDP that is post-linked to a delete version process in the MERGE state executes hsync.
  2. A user deletes the version created by the move item process.
  3. The delete version process supports the version system variable, but this support is not sufficient when the version represents a moved or renamed item. Hsync cannot find the name and path of the previous version when it is only given the name and path of a version that has already been deleted. Therefore, the delete version process uses the system variable for itemobjid. The post-linked hrefresh UDP uses both the version and itemobjid system variables and these values are passed to hsync.
  4. If hsync finds a file under /Build/Merge/Src that corresponds to the deleted version, hsync deletes the file.
  5. If the moved item was in a path under Src, hsync checks out the latest version of the item.
Use Case: Delete Version of Refactored Path
This use case presents synchronization of the items impacted by a delete version process.
  1. A user deletes a path version corresponding to a removed, renamed, or moved path. All descendant versions are deleted as a consequence.
  2. For each deleted version, a version and itemobjid system variable are passed to hsync.
  3. If hsync finds files under /Build/Merge/Src corresponding to the deleted versions, hsync deletes the files.
  4. If the impacted items are under Src, hsync checks out the latest versions of the items.
Use Case: Merge Refactored Items and Paths
This use case presents synchronization of the items impacted by a merge process.
  1. The hsync command deletes files in /Build/Merge/Src corresponding to previous trunk versions of items that were removed, moved, or renamed in the merge. If a removed/moved/renamed path was merged and if the directories are now empty except for signature file, hsync deletes directories corresponding to the older trunk versions.
  2. The hsync command checks out the latest normal-tagged trunk version of non-removed items in the inventory list to /Build/Merge/Src. If a merge-tagged version was created, the previous trunk version is checked out (if it was not already checked out). If a delete-tagged version was merged to the trunk, no version of the item is checked out.
Use Case: Promote Packages with Refactored Items and Paths
This use case presents synchronization of the refactored items impacted by a promote process.
  1. An hrefresh UDP is post-linked to a promote process in the MERGE state. All packages in the MERGE state are promoted together.
  2. The post-linked hrefresh UDP process executes hsync in both the MERGE state and in the INTEGRATION BUILD state using - pl with the package system variable.
  3. In the Merge state, hsync determines that no check-out is required because the reference directory type is Active and no packages exist in the state.
  4. In /Build/Merge/Src, hsync searches for files corresponding to checked-out versions of inventory items (items in promoted packages). Hsync deletes all such files. If the inventory contains paths, and directories corresponding to versions of those paths are now empty except for signature files, the directories are also deleted.
  5. In /Build/Integration/Src, hsync deletes files corresponding to inventory items that were removed, moved, or renamed in the promoted packages. If there are directories corresponding to removed/moved/renamed paths and those directories are now empty except for signature files, hsync deletes those directories.
  6. In the INTEGRATION BUILD state, hsync checks out inventory items in the BUILD view.
Use Case: Demote Packages with Refactored Items and Paths
This use case continues with the previous use case. Some of the packages that were promoted to INTEGRATION BUILD are now demoted back to MERGE. Those packages contain removed, renamed, and moved items and paths.
  1. The demote process in the INTEGRATION BUILD state has a post-linked hrefresh process that executes hsync in both the MERGE state and in the INTEGRATION BUILD state using - pl with the package system variable.
  2. In /Build/Integration/Src, hsync deletes files and directories corresponding to versions of inventory items that are no longer in the BUILD view. This action backs out demoted refactoring changes.
  3. In the INTEGRATION BUILD state, hsync checks out the latest versions of inventory items remaining in the BUILD view after demote. This action restores the files and directories in /Build/Integration/Src that were deleted in the previous use case due to promoted refactoring changes.
  4. Because /Build/Merge/Src was previously cleaned out by the promote process, it does not find any files to delete.
  5. In the MERGE state, hsync checks out the latest, normal-tagged, trunk version of nonremoved items and paths in the demoted packages.
Server, Client, and Agent Configuration
The
CA Harvest SCM
server, client, or agent do not require special configurations to use RDSU. You install and configure
CA Harvest SCM
agents on the reference computers. The agents can be single-user or multi-user, with access to the intended reference directories on each computer.
For more information about configuring
CA Harvest SCM
communication, see the
Installing section
.