Deploying EWM into a Rational ClearCase environment

The recommended deployment principle for the ClearCase Synchronizer is to configure the Rational® ClearCase and IBM® Engineering Workflow Management (EWM) deployments independently. For example, configure Rational ClearCase for the Rational ClearCase users (ignoring EWM), and configure EWM for the EWM users (ignoring Rational ClearCase). Then, deploy the ClearCase Synchronizer on a machine with efficient read-write access using a Rational ClearCase dynamic view to the Rational ClearCase stream (or branch) that is to be synchronized with EWM.

Rational ClearCase multisite considerations

Do not modify the Rational ClearCase MultiSite® deployment as a result of adding EWM. Likewise, do not modify the EWM deployment as a result of using Rational ClearCase MultiSite. When deploying the ClearCase Synchronizer, follow the standard guidance above. In particular, because the ClearCase Synchronizer must have write-access to the Rational ClearCase stream, the ClearCase Synchronizer for that Rational ClearCase stream must be deployed at a site where that stream or branch is mastered.

Selecting teams to use EWM

A team that is currently using (or is considering using) a source control system is a good candidate for using EWM. Ideally, developers on the team are Eclipse or Visual Studio users. Command-line access is provided for other users.

Assigning a component to a repository

When an organization uses both Rational ClearCase and EWM, it is recommended that each component (a set of files forming a logical unit of development) be assigned to a particular repository, such as a EWM repository or a Rational ClearCase VOB. It is recommended that the repository where a component is assigned be based on what repository is being used by the team that most commonly modifies that component. In particular, if a team is using EWM, it is recommended that the team be assigned to a single repository to ensure that the team can benefit from all of the collaborative capabilities of EWM. All components owned by that team are to be assigned to the repository for that team.

Read-only access to Rational ClearCase files by a EWM user

When a team using EWM needs read-only access to files that are assigned to a Rational ClearCase VOB, it can create a Rational ClearCase view that selects the required configuration of those files. Because this is read-only access, a single view can be logically shared by all of the developers who want to see that configuration.

Write access to Rational ClearCase files by a EWM user

When EWM users need write-access to files that are assigned to a Rational ClearCase VOB, they can do one of the following:
  • Create a personal Rational ClearCase view, and check in changes to the files in that view. Because Eclipse supports concurrent use of multiple-SCM providers in a single Eclipse workspace, users can use a single Eclipse workspace to change files in a EWM repository workspace and files in a Rational ClearCase view.
  • Use the ClearCase Synchronizer to create a ClearCase Synchronized Stream in the EWM repository, where a ClearCase Synchronized Stream is a EWM stream that is logically associated with a user-specified Rational ClearCase stream. This replicates user-selected files from the specified Rational ClearCase stream into the synchronized stream in the EWM repository and allows the user to use the EWM to modify both the files from their EWM repository and the (replicated) files from the Rational ClearCase repository. A synchronized stream is automatically synchronized periodically, such as nightly, with its associated Rational ClearCase stream. When a synchronized stream is synchronized, any changes delivered to the synchronized stream are applied to the Rational ClearCase stream, and any changes not checked in to the Rational ClearCase stream are applied to the synchronized stream. Any conflicts resulting from concurrent changes in EWM and Rational ClearCase to the same file or directory are automatically detected, and the standard EWM merge tooling is then used to resolve those conflicts.
The primary considerations in deciding if a EWM user must use a Rational ClearCase view or a ClearCase Synchronized Stream to modify files in a Rational ClearCase component are:
  • The number of files being changed: If the user needs write-access to a moderate number of files in a Rational ClearCase component (a few hundred), then using the ClearCase Synchronizer is preferred because the user does not have to set up a personal Rational ClearCase view.
  • The number of EWM users making changes to those files: If multiple EWM users are making changes to the same Rational ClearCase component, then using the ClearCase Synchronizer is preferred because the EWM users can take advantage of the EWM collaborative capabilities, while modifying those files.

Selecting a synchronization host

The host where the ClearCase Synchronizer is installed is called the synchronization host. The synchronization process that applies changes from Rational ClearCase to the EWM repository and from the EWM repository to Rational ClearCase runs on the synchronization host. The synchronization process must be able to read and write data in the EWM repository and Rational ClearCase VOBs.

Initial import

The resources used for a synchronize operation is proportional to the number of files that have changed and to the number of components that contain synchronized files (20-30 seconds per component). This includes the time to copy the content of each file that changed, plus two to six seconds to bring a changed file from Rational ClearCase to EWM, and an additional two to eight seconds to bring a changed file from EWM to Rational ClearCase.

The amount of time will vary based on the deployed database, the server that is running, and etc. An initial import of files from the Rational ClearCase stream to the synchronized stream is no different than a subsequent synchronization, except that because every file selected has changed, the resources used in the initial import is proportional to the number of files selected. In order to verify that there are no problems with the synchronization server configurations, it is recommended to first synchronize one or more files. After you have the first successful synchronization, you can then incrementally add file trees (a few hundred files at a time).

For example, a Rational ClearCase component containing 2,000 files with the root directory of /vobX/compA, and compA contains three Eclipse projects with the root directory of vobX/compA/proj1, /vobX/compA/proj2, and /vobX/compA/proj3, where proj1 contains 1,500 files, and proj2 and proj3 each contain 250 files.
	/vobX/compA
		/vobX/compA/proj1 (1,500 files)
		/vobX/compA/proj2 (250 files)
		/vobX/compA/proj3 (250 files)
To get started, first select a single file to be synchronized, such as /vobX/compA/proj2/src/parser/main.c. If that synchronize is successful, then the synchronization server is correctly configured, and you can now synchronize /vobX/compA/proj2. After the synchronization is successful, you can request that the remainder of the files be synchronized. Because proj3 contains 250 files, /vobX/compA/proj3 can be specified as a directory to be synchronized.

Because proj1 contains a large amount of files (1,500), it is recommended to import in several batches. For example, suppose that proj1/src contains five subdirectories, named db, db-core, protocol, repo, and admin, each with about 300 files. First import the file directories, such as /vobX/compA/proj1/src/db, vobX/compA/proj1/src/db-core. If those five synchronizations succeed, then import /vobX/compA/proj1. After all projects are successfully imported, you can import /vobX/compA. After you have successfully synchronized a directory, you can remove any children of that directory from the list of files and directories to be synchronized. In this example, after /vobX/compA is imported, you can remove all of the previous files and directories from the selected for synchronization list.

Stream synchronization

After you no longer need write-access to any of the files in a given synchronized directory, it is recommended that you remove that directory from the list of directories to be synchronized, so that you no longer synchronize changes to the files in that directory. This frees synchronization resources for new sets of files that you might need to modify.

A directory that is removed from the list to be synchronized can be restored, but this is considered a new import, which will overwrite the current state of the files with the current file states of the files in the other repository. Conflicts are not detected or reported. As a result, the change-set from adding back a previously synchronized directory needs to be inspected to ensure that no unexpected overwrites have occurred. These change sets are automatically given a comment indicating that they need inspection.

If you only need a subtree under a synchronized directory, you can add the root directory of that subtree as a directory to be synchronized and then remove the parent directory from the list of directories to be synchronized. It is recommended to first add the subdirectory and then remove the parent directory to avoid the re-import of the subdirectory. This is more efficient because it eliminates the need for the re-import of the subdirectory and is more reliable because there is no risk of losing changes made in EWM between the removal of the parent and the re-import of the subdirectory.

Selecting the Rational ClearCase stream to synchronize

As indicated in the import section, the resources used in a synchronize operation are primarily proportional to the number of changed files. Note that although the synchronization stream in EWM is always open for additional deliveries, the Rational ClearCase stream is locked while a synchronization is taking place. If a small number of changes are made each day, and the synchronization is scheduled at a time when nobody is attempting to check in changes to that Rational ClearCase stream, then you can synchronize with a Rational ClearCase integration stream. However, if the lock on the integration stream during synchronization is interfering with normal development on that stream, it is recommended that you create a new Rational ClearCase development stream for the synchronized stream and to re-target the synchronized stream to that new development stream. It is then necessary for the user (or a scheduled job) to periodically re-base that development stream to refresh the changes to the Rational ClearCase integration stream.


video icon Video

Jazz.net channel
Software Education channel

learn icon Courses

IoT Academy
Skills Gateway

ask icon Community

Jazz.net
Jazz.net forums
Jazz.net library

support icon Support

IBM Support Community
Deployment wiki