Each process in a lifecycle can have one or more processes linked to it. The following methods of process linking are available:
Note: The pre-linked method is unavailable for the command-line utility except for the promote and demote processes.
The order of display in the Pre-Linked or Post-Linked tabs determines the order of the linked process execution. Your CA Harvest SCM session is suspended during execution of linked processes. If multiple processes are linked to one parent process, the execution of each depends on the success of the previous one. If a linked process or the parent process fails, none of the remaining processes execute including the parent process.
Note: You must set up linked processes so that they do not require any input from the user upon execution. If the input is insufficient for execution, the process fails.
Processes are considered objects in CA Harvest SCM, so the same rules that govern other object access apply to processes with one exception: Processes that are linked to another process have no access control of their own. They are secured through the access control associated with the process to which they are linked.
The client computer executes allCA Harvest SCM processes, with the exception of UDPs. If a process must run on a computer other than the client, you can define a UDP to run it.
CA Harvest SCM can only access directories on computers where a CA Harvest SCM agent is running. For example, during check-in processes verify that the files you want to check in are located on an appropriate client. When the files you want are on remote computers, you can use operating system tools, such as the Network File System from Sun Microsystems or the Distributed File System from the Open Software Foundation, to distribute the files.
External processes invoked through UDPs or notifications are executed in synchronous mode. After a user-defined or notification process starts, you cannot perform keyboard actions until the process completes.
The Approve Properties dialog lets you define the users and user groups who must give their approval before they can promote or move a package out of the associated state.
Note: To prevent users from changing a package while it is pending approval, we recommend that you create a state named Approve to which users can promote packages. Do not define any processes in the state that would allow users to change packages (for example, check-out for update, check-in, delete versions, and so on).
For a post-linked process to run, all packages must be approved. If the approval of any selected package fails, post-linked processes do not execute. If any of the pre-linked processes fail the approvals do not execute.
A user can reject a package when it does not meet standards. If a member of a group rejects a package, that particular user must approve the package to remove the rejection; the approval of another user in the group does not override it. If it is necessary to override a rejection, you can add a second approval process.
Follow these steps:
The Processes folder is listed in the workspace.
The Approve Properties dialog appears.
Specifies all users who are responsible for approving packages. You can add one or more users to the approval list by clicking Add to open the Add Users dialog. You can delete users by selecting one or more names from the Users list, and clicking Delete.
Specifies all user groups who are responsible for approving packages. You can add one or more user groups to the approval list by clicking Add to open the Add User Groups dialog. You can delete user groups by selecting one or more names from the User Groups list, and clicking Delete.
Approvers are defined for the process.
Saves the process definition, but does not close the dialog.
The approve process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The Promote Properties dialog lets you define a promote process. The setting of the options on this dialog determine the choices the user can make when executing the promote process:
Follow these steps:
The Processes folder is listed in the workspace.
The Promote Properties dialog appears.
Forces all the packages belonging to a bound package group to be promoted together; otherwise, an error occurs.
Prohibits packages from being promoted to the next state if they are associated with branch versions. If you enforce that packages must be merged, the latest change for the package must be on the trunk, not on a branch. If the promote process is in a state with no view, or if that state's view is the same as the one in the Promote To state, this option is not enforced.
Disallows promotion of packages that depend upon other packages. Dependency is based on versions in the view. In the current state, a package with a higher item-version cannot be promoted without also promoting the packages with the lower item-versions in the current view, unless the lower item-versions exist in the view of the Promote To state. If the promote process is in a state that shares the same view as the one in the Promote To state, this option is not enforced.
Note: The lower item-version causes a dependency error only when it is on the trunk.
The process is defined.
Saves the process definition, but does not close the dialog.
The promote process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The Demote Properties dialog lets you define a demote process. The setting of the options on this dialog determine the choices the user can make when executing the demote process:
Pre-Linked processes execute before packages change states, and Post-Linked processes execute after packages change states. The failure of a Pre-Linked process generates an error and causes the demote process to fail. The state of the packages changes only after the successful completion of all Pre-Linked processes. Typically, a notify process is pre-linked to the demote process.
Follow these steps:
The Processes folder is listed in the workspace.
The Demote Properties dialog appears.
Enforces all the packages belonging to a bound package group be demoted together; otherwise, an error occurs.
Prevents demotion of packages upon which other packages depend. Dependency is based on versions in the current view. In the current state, a package with a lower item-version cannot be demoted without also demoting the packages with the higher item-versions in the current view. If the demote process is in a state that shares the same view as the one in the Demote To state, this option is not enforced.
Note: The higher item-version causes a dependency error when it is on the trunk or on the branch.
The process is defined.
Saves the process definition, but does not close the dialog.
The demote process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The check-in process creates a version of an item by bringing the changes made to a file into the current view path, and optionally releases the reserved status of the parent version in the repository. The Checkin Properties dialog lets you define the check-in process.
Follow these steps:
The Processes folder is listed in the workspace.
The Checkin Properties dialog appears.
The options will be available to users on the process execution dialog.
The process dialog will display the default values and the user can override them.
The process definition is saved.
The check-in process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The Checkin Properties dialog lets you select options to be available to users on the process execution dialog and specify defaults for various execution options. Following are the available options and their descriptions:
Checks in files when the package reserves them or when they do not exist in the repository. This filter does not require the corresponding item to be in the current view. However, if it is in the current view, it must have a reserved version in the current package.
Limits the check-in to files that do not have corresponding items in the current view.
Limits the check-in to files that have corresponding items reserved by the package. Any files without corresponding items are skipped.
Prevents a user from releasing a version if that user did not initially reserve it. By default, any user can release a reserve‑tagged version by checking in a copy of the reserved item.
Forces the user to enter a description to check in successfully.
Note: If you select the Enforce change description option and if the Display silent check in command in menus option is selected in Visual Studio .NET, users will get an error message and the check-in process may not be successful.
Limits the check-in to files that do not have corresponding items in the current view and creates trunk versions.
Limits the check-in to files that do not have corresponding items in the current view and creates branch versions. If an item exists on the branch, a user can check in the item to a branch in a different view. This option supports concurrent development of the same file using different packages. For example, if user1 uses package1 to check in file1.txt, a x.1.1 version is created. User2 can check in the same file (file1.txt) using package2 to the same view on a branch as x.2.1 version.
Note: The New Items on Trunk and New Items on Branch options are disabled when the user selects Existing Items Only; otherwise, one or both can be selected. If the user only selects New Items on Trunk, new items can only be checked in to the trunk. If the user only selects New Items On Branch, new items can only be checked in to the branch. If the user selects both, new items can be checked in to either the trunk or the branch.
The Defaults tab lets you specify default options. When a user opens the process execution dialog, the default values are displayed and the user can override them.
Updates or creates the item in the view and it is no longer reserved by the package. Sets the file permission to read‑only so that changes cannot be made to the file until it is checked out again.
Updates or creates the item in the view . The current package keeps the item reserved and checked out so that the user can modify the item.
Releases the reserved tag, no check-in is performed, and the item is not updated. The file permission is set to read-only, indicating that changes should not be made to the file until it is checked out.
Specifies the default item filters; a disabled filter value cannot be selected as a default.
Note: Select the Existing Items Only for the default item filter to prevent your repository from being cluttered up with unwanted files. It is common during development to create temporary files or templates in a working directory. If all files are selected during check-in, these unwanted files can be included, although they are not a meaningful part of the application being controlled.
Checks in selected files to paths with names that correspond to their client directory location, if these paths currently exist.
Checks in selected files to paths with names that correspond to their directory location, and creates any view paths that do not currently exist.
Checks in all selected files to the same path in the destination view, ignoring the client directory structure.
Controls whether files checked in should be deleted from the client file system at the completion of the check-in process.
Provides up to 2,000 characters of descriptive text for the check-in process. This text shows on the process execution dialog and lets you inform users what the process does. You are not required to enter anything in this field. If the process is linked to another, the description is invisible during execution.
The check-out process copies a version of an item to the file system, optionally reserving the version in the current view or on a branch. The Checkout Properties dialog lets you select the check-out mode or modes to allow, and specify default values for various execution options.
Follow these steps:
The Processes folder is listed in the workspace.
The Checkout Properties dialog appears.
The options will be available to users on the process execution dialog.
The process dialog will display the default values and the user can override them.
The process definition is saved.
The check-out process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The Checkout Properties dialog lets you select options to be available to users on the process execution dialog and specify defaults for various execution options. Following are the available options and their descriptions:
Checks out the items to the destination directory but does not reserve the item and does not allow the user to check the files back in. The read-only attribute is set on files checked out in Browse mode.
Copies selected versions to the destination client directory and creates a reserved version on each item's trunk, allowing the corresponding files to be checked in. The permission on a read-only file is changed to normal (write access) when this mode of check-out is used.
Creates a reserved version on each item's trunk, but does not move any data to external directories.
Identifies the versions of the files in the client file system by using the signature file. CA Harvest SCM versions are checked out only if the signature file shows:
Items are checked out in a read-only mode. The check-out for Synchronize mode is especially useful in the build process.
Copies selected versions to the destination client directory and creates a reserved version on a package branch for each item. All package updates accumulate on this branch. The permission on a read‑only file is changed to normal (write access) when this mode of check-out is used.
Notification is sent to all users that have checked out the item for concurrent update, including items updated in different CA Harvest SCM projects.
Note: Creating a check-out process that allows only Browse mode can be useful in a QA or testing state where no updates are made. To design a lifecycle with enforced package branching, allow only check-out for Concurrent update in certain states.
Replaces read-only files on the UNIX file system regardless of file ownership; this option is useful when two or more developers share the same working directory. By default, CA Harvest SCM replaces read-only files on a UNIX client system only if the user executing the check-out process is the owner of the files.
This option also affects the ownership of client directories created by the check-out process when the Preserve and create directory structure option is used. Without Shared working directory selected, directories created during check-out have write access only to the user who executes the check-out process. When Shared Working Directory is selected, all new directories created during check-out have group write access.
Note: All directories being checked out to must have group write access, and all users sharing the working directories must be in the same UNIX group.
Restamps the file with the time at check‑out; otherwise, the current system time is used.
The Defaults tab lets you specify default options. When a user opens the process execution dialog, the default values are displayed and the user can override them.
Checks out all selected items into corresponding client directories, if they exist.
Checks out all selected items into corresponding client directories and creates any client directories that do not currently exist.
Places all selected items directly beneath the specified client directory, ignoring the path structure in the repository.
Controls whether the checked-out files should replace existing read-only files on the client file system. This option lets you replace files that you previously checked out as read-only or checked in.
Note: On UNIX platforms, the Replace Read-Only Files option replaces files only if the user who is executing the check-out process owns them.
Files that are not read-only on a Windows file system or that have write permission on the UNIX file system are never overwritten.CA Harvest SCM assumes that such a file has been checked out for Update and not checked back in yet. Overwriting such a file might cause a user to lose unsaved changes.
If no corresponding file exists on the host, the item is checked out regardless of the value for this option.
The compare view process generates an overview report showing a summary of the differences between any two views, either snapshot or working, that exist in any project. This report generates three lists:
You can also use the process to see the difference between two items or sets of items, rather than an entire view.
Pre-Linked and Post-Linked processes execute before and after you click Compare View on the process execution dialog.
Follow these steps:
The Processes folder is listed in the workspace.
The Compare View Properties dialog appears.
Saves the process definition, but does not close the dialog.
The compare view process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The create package process lets users create packages and optionally, corresponding forms. The Create Package Properties dialog lets you define a create package process and specify whether a form should be created and automatically associated with the package created by this process, and if so, what kind of form. You can also specify an initial state for the package to be created in and a default name for packages created with this process.
You can link notify and UDP processes to a create package process using the Pre-Linked or the Post-Linked process. Linked processes execute after OK or Apply is clicked on a package/form combination.
Follow these steps:
The Processes folder is listed in the workspace.
The Create Package Properties dialog appears.
Lists all the states in the lifecycle of the current project. Select the state that packages created by this process should begin the lifecycle in. When the user executes the process, the package is created in this state regardless of the state from which the process was invoked.
Lists the currently installed form types. If you check the Create Automatically option, this field becomes active and you can select the type of form to be created.
Creates a form with the same name as the package created by this process and associates them.
Specifies a default name for the package and form to be created by this process. The user executing the process can modify the name.
Prohibits the user from changing the package name. This field should be disabled for text-only template names; otherwise, users will not be able to create more than one package with the process.
Note: A blank Default Name is allowed for DBMS triggers even if this option is selected.
Options are defined for the process.
Saves the process definition, but does not close the dialog.
The create package process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
You can set the Create Package Properties dialog to specify a default name for the package and form that the create package process creates. For example, you might want all package names to begin with a certain prefix such as Bug #.
The default name can include formats to generate dates or numbers automatically by including database management system (DBMS) format models in the Default Name field, as shown in the following table.
|
Default Name |
Comment |
Results |
|
CR-%N('99') |
Insert an incremental number |
CR- 1, CR- 2, CR- 3,... |
|
MR-%N('009') |
Incremental number, zero padding |
MR- 001, MR- 002, MR- 003,... |
|
PKG%N('009MI') |
Incremental number, zero padding, trailing minus |
PKG001, PKG002, PKG003,... |
Note: By default, the DBMS format returns positive numbers with a leading space that is reserved to hold a plus sign (+). You can suppress this behavior by including the 'MI' (trailing minus) as the last characters in the format string as shown in preceding examples.
The cross project merge process merges changes made to items in one project with the changes made to the same items in another project. The cross project merge creates versions in the target project that are the latest for each item on the trunk.
The cross project merge process is especially useful in parallel development, when the same items are changed in two different projects.
You can link notify and UDP processes to a cross project merge process using the Pre-Linked or the Post-Linked process. Linked processes execute before and after the merge is complete.
Follow these steps:
The Processes folder is listed in the workspace.
The Cross Project Merge Properties dialog appears.
Creates a merge-tagged version, regardless of the contents of the versions. The process fails if the target package has an unmerged branched version of an item that is also in the source package.
Creates a merge-tagged version only when conflicts are found. If no conflicts are found, the branch and trunk versions are merged to create a normal version. Normal tags can only be created when the versions being compared are in the original baseline of both projects. If the versions are checked in after baselining, merge tags are created regardless of whether conflicts exist.
Note: A conflict occurs when a line or block of data is modified in both the source and the destination; insertions and deletions are not conflicts.
Automatically selects the destination (trunk) to create the final version, without comparing the contents of the versions. This option creates a normal version on the destination trunk and closes the source branch version.
Automatically selects the source branch version to create the final version, without comparing the contents of the versions. This option creates a normal version on the destination trunk and closes the source branch version.
Creates a version on the target branch. This option allows changes to be copied from the source project to the target project even if one or more target items are reserved for update in the main trunk. A branch is created to store the changes. The target package cannot be the same package that contains the items reserved for update on the main trunk.
Creates a version on the target trunk.
Creates a version on the target trunk or branch. This option allows changes to be copied from the source project to the target project even when one or more target items are reserved for update in the main trunk. If items are reserved for update on the trunk, a branch is created to store the changes only if the target package is not the same package that contains the items reserved for update. If items are not reserved for update on the trunk, the items are simply copied to the trunk.
Options are defined for the process.
Saves the process definition, but does not close the dialog.
The cross project merge process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The delete package process lets CA Harvest SCM users delete packages and lets administrators differentiate users who can edit a package from those users who are allowed to delete a package. Users belonging to user groups who are allowed to execute a delete package process associated with a package state can delete packages and the forms associated with the packages.
Follow these steps:
The Processes folder is listed in the workspace.
The Delete Package Properties dialog appears.
Saves the process definition, but does not close the dialog.
The delete package process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The delete version process allows users to remove selected versions of items from the CA Harvest SCM repository.
You can link notify and UDP processes to a delete version process by using the Pre-Linked or the Post-Linked process. These processes execute before and after the delete version process completes successfully. In this case, successfully means that at least one version is deleted.
Follow these steps:
The Delete Version Properties dialog appears.
Note: If you select this option, only the creator or modifier or administrator would be able to delete the version.
Saves the process definition, but does not close the dialog.
The delete version process is now added to the state. The process name appears in the Processes menu and in the title bar of the process execution dialog.
The List Version Properties dialog lets you specify defaults for various execution options. When a user invokes the process execution dialog, the values specified with the properties are displayed as initial defaults and the user can override them.
The list version process lets users generate reports about the changes made to items in the current project. The listing produced by this report is in the same format as that produced by the UNIX diff command.
Linked processes execute before and after the list version process completes successfully. In this case, “successfully” means that at least one version is listed.
Follow these steps:
The Processes folder is listed in the workspace.
The List Version Properties dialog appears.
Saves the process definition, but does not close the dialog.
The list version process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The move item process lets users logically move an item from the current path to another path. The movement is included as a change associated with a package and can progress through the lifecycle as the package is promoted from one view to another. When an item has been moved, it no longer displays under the original path in the item view. The move item process creates a new version located on the new parent path. This version has properties like other versions and can be seen in the List view by double-clicking the item or through the Find Version dialog.
Linked processes execute before and after the move item process completes successfully. In this case, "successfully” means that at least one item is moved.
Follow these steps:
The Processes folder is listed in the workspace.
The Move Item Properties dialog appears.
Creates a trunk version for refactoring changes. (This option is identical to the check-out for update process.)
Creates a branch version for refactoring changes. (This option is identical to the check-out for concurrent update process.)
Creates a normal version for the refactoring change. If a reserved version already exists in the same package, it is updated as a normal version.
Creates a normal version for refactoring changes. Another new reserved version is created after the normal version.
The options are selected for the process.
Saves the process definition, but does not close the dialog.
The move item process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The move package process moves a package from a state in one project to a state in another project. The move package process is similar to the promote process. Promote moves a package forward from one state to another in a project. As with the promote process, if the state has approval processes, they are verified before the package is moved.
Unlike promote, the move package process moves only the package definition and history, not any versions associated with the package in the current project. If versions are associated with a package, it cannot be moved.
To execute this process, users must have access to the create package process in the destination project and state.
Important! If you delete a state that was the target of a move package process, the process must be deleted or redefined with a new target state.
Linked processes execute before and after all the selected packages are moved to the target project. If any package fails to be moved, the post-linked processes do not execute.
Follow these steps:
The Processes folder is listed in the workspace.
The Move Package Properties dialog appears.
Lists all the projects in the current CA Harvest SCM installation. Select the default destination project for the package. If you want to allow CA Harvest SCM users to select a project, select <any>. If <any> is selected, the To State field is also reset to <any>.
Lists all the states in the current project. Select the default state in the destination project for the package. If you want to allow CA Harvest SCM users to select a state, select <any>.
The name and destinations are defined for the process.
The process is defined.
Saves the process definition, but does not close the dialog.
The move package process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The move path process lets users logically move a path from the current location to another path. The movement is included with the changes associated with a package and can progress through the lifecycle as the package is promoted from one view to another. When a path has been moved, it no longer displays under the original path in the item view. The move path process creates a version located on the new parent path. This version has properties like other versions and can be seen under the package's Versions folder.
When you move a path, the move path process also creates one new version for each item and path under this path. All those versions are combined as one change; individual versions cannot be deleted. Deleting the original moved path version automatically deletes all the sub-item/path versions created by that move path process.
Linked processes execute before and after the move path process completes successfully. In this case, “successfully” means that at least one path is moved.
Follow these steps:
The Processes folder is listed in the workspace.
The Move Path Properties dialog appears.
Creates a trunk version for refactoring changes. (This option is identical to the check-out for update process.)
Creates a branch version for refactoring changes. (This option is identical to the check-out for concurrent update process.)
The following mode options are applicable only for subitems:
Creates a normal version for the refactoring change. If a reserved version already exists in the same package, it is updated as a normal version.
Creates a normal version for refactoring changes. Another new reserved version is created after the normal version.
The options are selected for the process.
Saves the process definition, but does not close the dialog.
The move path process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
Note: The instances of Linux in this section refer to both the Linux and zLinux operating environments.
The Notify Properties dialog lets you define the process and specify defaults for various execution options. When the user invokes the process execution dialog, the user can override the default values.
The notify process uses standard MAPI or SMTP mail services to let you send a message to any combination of users and user groups. You can add this process to a state or link it to other processes so designated users are notified automatically during the execution of the parent process.
Linked processes execute before and after the initial notify process completes successfully.
Follow these steps:
The Processes folder is listed in the workspace.
The Notify Properties dialog appears.
Specifies a mail program and any arguments you want to supply when the program is invoked. On Windows clients, the server computer executes the mail program and must be in the path of the user who started the server.
Default: mail
Specifies a default subject. This subject appears on the subject line of the email message when it is sent. Users can modify the content of this field when it is not set up as a linked process. For AIX and Linux operating systems, the Subject field cannot contain double quotes.
Note: If you are using hsmtp.exe and define a subject separately in the hsmtp.arg file, do not include a value in this field.
Specifies a default mail message for the process. You can enter up to 2,000 characters. For example, if this process is going to be used to notify a manager that a package has been promoted, you can specify the appropriate message in this field. If the notify process is being linked to another process, you can use system variables in the messages to represent various parameters.
Specifies a default action to be taken with any general or error outputs generated by the notify process. The choices are Display or Discard. All output is automatically appended to the output when the Display choice is selected.
Specifies the users to receive the notification. You can add a user to the list by clicking Add, selecting the user, and clicking OK. You can delete a user from the list by selecting the user, and clicking Delete.
Specifies the user groups to receive the notification. To be notified, users in the group must have use access to the project unless they are listed in the Users to Notify list. You can add a user group to the list by clicking Add, selecting the user group, and clicking OK. You can delete a user group from the list by selecting the user group, and clicking Delete.
The process is defined.
Saves the process definition, but does not close the dialog.
The notify process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The remove item process lets users logically delete selected items from a view. The removal is made part of the changes associated with a package and can then progress through the lifecycle as the package is promoted from one view to another.
When an item has been removed from a view, it is no longer displayed in item view. However, the item is not deleted; the remove item process creates a new version tagged as removed (D). This version has properties like other versions and can be seen in the list view by double-clicking the item or through the Find Version dialog.
Linked processes execute before and after the remove item process completes successfully. In this case, “successfully” means that at least one item is removed.
Follow these steps:
The Processes folder is listed in the workspace.
The Remove Item Properties dialog appears.
Creates a trunk version for refactoring changes. (This option is identical to the check-out for update process.)
Creates a branch version for refactoring changes. (This option is identical to the check-out for concurrent update process.)
The options are selected for the process.
Saves the process definition, but does not close the dialog.
The Remove Item process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The remove path process lets users logically remove a path. The removal is included with the changes associated with a package and can progress through the lifecycle as the package is promoted from one view to another. When a path is removed from the trunk, it no longer displays in the item view. The remove path process creates a version tagged as removed (D). This version has properties like other versions and can be seen under the package's Versions folder.
When you remove a path, the remove path process also creates one new version (D) for each item and path under this path. All those versions are combined as one change; individual versions cannot be deleted. Deleting the original removed path version automatically deletes all the sub-item/path versions created by that remove path process.
Linked processes execute before and after the remove path process completes successfully.
Follow these steps:
The Processes folder is listed in the workspace.
The Remove Path Properties dialog appears.
Creates a trunk version for refactoring changes. (This option is identical to the check-out for update process.)
Creates a branch version for refactoring changes. (This option is identical to the check-out for concurrent update process.)
The options are selected for the process.
Saves the process definition, but does not close the dialog.
The remove path process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The rename item process lets you rename an item. After you execute the process, the rename item process creates a version with a new name. The previous versions of the item exist with their former names and you can see it in the version view of the item.
Follow these steps:
The Processes folder is listed in the workspace.
The Rename Item Properties dialog appears.
Creates a trunk version for refactoring changes. (This option is identical to the check-out for update process.)
Creates a branch version for refactoring changes. (This option is identical to the check-out for concurrent update process.)
Creates a normal version for the refactoring change. If a reserved version exists in the same package, it is updated as a normal version.
Creates a normal version for refactoring changes. Another new reserved version is created after the normal version.
The options are selected for the process.
Saves the process definition, but does not close the dialog.
The rename item process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The rename path process lets users logically rename a path. The renamed path is included with the changes associated with a package and can progress through the lifecycle as the package is promoted from one view to another. When a path has been renamed, it no longer displays the old name in the item view. The rename path process creates a new version with the new name. This version has properties like other versions and can be seen under the package's Versions folder.
When you rename a path, the rename path process also creates one new version for each item and path under this path. All those versions are combined as one change; individual versions cannot be deleted. Deleting the original renamed path version automatically deletes all the sub-item/path versions created by that rename path process.
Linked processes execute before and after the rename path process completes successfully.
Follow these steps:
The Processes folder is listed in the workspace.
The Rename Path Properties dialog appears.
Creates a trunk version for refactoring changes. (This option is identical to the check-out for update process.)
Creates a branch version for refactoring changes. (This option is identical to the check-out for concurrent update process.)
The following mode options are applicable only for subitems:
Creates a normal version for the refactoring change. If a reserved version already exists in the same package, it is updated as a normal version.
Creates a normal version for refactoring changes. Another new reserved version is created after the normal version.
The options are selected for the process.
Saves the process definition, but does not close the dialog.
The rename path process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The switch package process lets you move versions from a source package to a target package.
Follow these steps:
The Processes folder is listed in the workspace.
The Switch Package Properties dialog appears.
Saves the process definition, but does not close the dialog.
The switch package process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
The take snapshot process lets users create snapshot views of their current working view.
Snapshot views are read-only images of working views that were modified before or on a specified date and time. Snapshots let you capture a software inventory at significant points in its development. After you create a snapshot, you can use it to support other application management functions, such as baselining or recreating an application at a modified version date.
Linked processes execute before and after the snapshot is created.
Follow these steps:
The Processes folder is listed in the workspace.
The Take Snapshot Properties dialog appears.
Saves the process definition, but does not close the dialog.
The take snapshot process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
Note: The instances of Linux in this section refer to both the Linux and zLinux operating environments.
The User-defined Properties dialog lets you specify an external program to run as a process in your lifecycle. You can add this process to a state or linked to any other process. Linking UDPs to other processes lets you execute any set of user‑defined actions as a result of the previous action.
Note: If this process is linked to another process, all required input must be defined in the properties dialog.
When your site uses numerous UDPs where you must change each UDP definition manually, the maintenance becomes cumbersome.You can minimize your maintenance effort by avoiding the use of:
Instead, as permanent alternatives, use the following options:
To define a user-defined process
The Processes folder is listed in the workspace.
The UDP Properties dialog appears.
Names the executable file that you want to run. Specify a full path to the program.CA Harvest SCM searches for a path in the PATH variable of the user invoking the process, or in the case of a server UDP, in the PATH variable of the server system. To locate and select a program, click the browser button to invoke the Windows file browser.
When the CA Harvest SCM hsql relational database query command line is used in the Program field:
Note: For more information about the CA Harvest SCM hsql command line, see the Command Line Reference Guide.
Specifies the location of the program to be executed.
Default: Client.
Specifies input to the program you have specified. Many programs read input from the default input device. This option only applies to programs that read from the standard input device.
Limits: Up to 2,000 characters of input can be specified.
Defines the information in the Input field as modifiable in the process execution dialog. By default, this field is not modifiable. To allow users to modify the default input, clear the Secure Input check box.
Specifies that a stand-alone client UDP (not linked to any process) does not prompt with a process execution dialog.
Specifies that no additional command line parameters are provided for this UDP process.
Specifies a default action to be taken with any general or error output generated by the associated process. You can choose one of the choices for both fields: Display or Discard. Selecting Display automatically appends the entire output.
Specifies up to 255 characters of descriptive text for the user-defined process. This text shows on the process execution dialog and lets you inform users about what the process does. You are not required to enter anything in this field. If the process is linked to another, the description is invisible during execution.
The user-defined process is complete.
Saves the process definition, but does not close the dialog.
The user-defined process is added to the state and the process name appears in the Processes menu and in the title bar of the process execution dialog.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|