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