Overview

Rational ClearCase uses a view model combined with a virtual file system that allows you to specify the lineup of file versions with which you want to work. Rational Rose RealTime then sees the files in the current view just as if they were stored on a regular (non-ClearCase) file system. Rose RealTime specifies the set of files that make up the model, and ClearCase provides the versions of these files determined by the view's configuration specification.

 For detailed information on using Rose RealTime with ClearCase, see the document titled Guide to Team Development, Rational Rose RealTime.

Before using ClearCase, you need to set up your workstation and any workstations on which ClearCase will be used.

Prerequisite: Setting up ClearCase

General Recommendations

If you are a Microsoft Windows NT user, do not access views through the MVFS mount point or M: drive. Instead, use the views through explicit drive mountings, such as X:, Y:, or Z:. This improves wink-in and eliminates dependencies on view names.

UCM Integration

The UCM Integration lets you assign activities to revisions from within the tool sets, if you are working in a UCM VOB. Additionally, you can Rebase, Deliver, and launch the Project Explorer from within Rose RealTime.

Snapshot Views

With ClearCase, you can initiate a snapshot view update from within Rose RealTime. The snapshot view contains the directory tree of source files.

You will want to use snapshot views if any of the following conditions apply:

• Your computer does not support dynamic views.
• You want to optimize build performance to achieve native build speeds.
• You want to work with source files under ClearCase control when you are either disconnected from the network that hosts the VOBs, or connected to the network intermittently.
• You want access to a view from a computer that is not a ClearCase host.
• Your project does not use ClearCase build auditing and build avoidance.

Rational ClearCase Workstation Setup

All workstations that will be accessing a VOB or view, must be set up to use ClearCase. For Windows NT/2000, this includes all workstations used for development. For UNIX, this includes all machines that are view servers.

Additionally, all machines that act as view servers for the ClearCase views used by Rose RealTime, must be set up for ClearCase. If you use ClearCase MultiSite, you will need to do this at all the sites where the VOBs containing the Rose elements are replicated. You can determine which machines are view servers by typing the following in a command window:

 cleartool lsview

The second item on each output line indicates the machine name where the view server is running. For example, if you see the following line in the output of the lsview command:

 myview mymachinevwsmyview.vws

then "mymachine" is the name of the machine where the view server for myview exists.

 For further details, see your ClearCase administrator or see the information on source control tools in the Guide to Team Development, Rational Rose RealTime.

Initial Setup

The following steps apply if you will be working on a model that is already under source control in a VOB. For additional information, see the information on source control administration in the Guide to Team Development, Rational Rose RealTime.

1. Create the integrator view so that the configuration specification appears as follows:

 
element * CHECKEDOUT


 
element * /main/LATEST

2. Create project labels to define various lineups. Examples of significant labels are:

• TC_BASELINE_0 - to represent the initial state of the project
• TC_BUILDFILES - to indicate which element versions should be included in the next automated build
• TC_LATEST_STABLE - to identify the most recent stable lineup on the integration branch

3. Create the initial lineup and apply the label to the VOB. An example of an initial lineup is:

 
[x:dev]cleartool mklabel -recurse TC_BASELINE_0 dev

4. Create the developer view template to ensure that all config specs are derived from a common base. This provides consistent and controlled access to the model, and eases the usage of lineups and private branches.
   
   There are two primary functions that developers will be performing; browsing and development. Each requires a different config spec.

 For information on the template rules, see the initial setup information in the Guide to Team Development, Rational Rose RealTime.

Tool Steps

To use ClearCase from Rose RealTime, follow these steps:

1. Control appropriate model elements as units
2. Create a local work area
3. Save a model to the work area
4. Configure the workspace source control options
5. Add the model to source control
6. Make the default workspace available to all project members
7. Use view templates
8. ClearCase entities
9. Automate builds
10. Developer process
11. Integration process

1. Control appropriate model elements as units

Determine the granularity you require for your project and team environment at the current stage in development. Do this in collaboration with the architect for the project.

2. Create a local work area

You will want to establish a local work area to save models in ClearCase. Each developer accessing Rose RealTime files in a VOB should use their own dedicated view.

3. Save a model to the work area

Before placing the model under source control, it must be saved to the local work area. Save the model to the directory you have associated with your source control repository.

4. Configure the workspace source control options

To enable source control, fill in the appropriate settings described in the source control fundamentals in the Guide to Team Development, Rational Rose RealTime.

5. Add the model to source control

The simplest way to add all applicable units to source control is to use the Submit All Changes to Source Control tool. See the source control administration information in the Guide to Team Development, Rational Rose RealTime for more information.

6. Make the default workspace available to project members

The workspace (.rtwks) file contains information that is common to all users working on the project. Settings in the workspace will rarely, if ever, change after it is initially set up. All developers on a project should use identical copies of the workspace file. For this reason, you may want to place this file under source control so that a fixed version is available to all project users. Rational Rose RealTime does not provide explicit support for checking in or checking out this file.

After the source control manager adds the model to source control, the workspace should be manually added using your source control tool. Other users should then retrieve the workspace as part of their initial update of their local work area. This ensures that all team members use the same source control settings for the project.

7. Use view templates

View templates are used to ensure that developers use a common base for their view's config spec and to make it easier to work on private branches. A view template specifies the integration branch to work from, lists labeled checkpoints that can be used to base a private branch on, and includes a config spec template that can be filled in with additional config spec rules.

 See the Rational ClearCase parallel development information in the Guide to Team Development, Rational Rose RealTime for more information.

8. ClearCase entities

Views, view templates, and labels can be created to help facilitate Rational ClearCase features. See the ClearCase parallel development information in the Guide to Team Development, Rational Rose RealTime for more information.

9. Automate builds

To provide the ability to selectively choose the versions of files that go into the build, the builder selects all versions that are labeled with the build label TC_BUILDFILES. This allows flexibility in changing the exact versions that go into the build if needed. For example, if the most recent version of a file contains code that does not compile, then the previous version can be labeled instead.

The following steps are involved in the build:

1. Label the build files.
2. Perform the build.
3. When the build completes successfully:
4. • Create a new lineup label and apply to build file versions.
   • Apply TC_LATEST_STABLE to build file versions.
   • Make the new lineup available to developers.

10. Developer process

Each development activity is completed by a single developer and is performed on a private branch specific to that activity. Again, each developer requires his or her own view. The view is based on a branching point on the integration branch identified by a build label.

A unique branch name must be chosen that identifies the work being performed, such as:

 paulz_timing

The view's config spec rules are set up to automatically check out and branch files from the branching point to the private branch. As well, new elements created during the development activity are immediately branched to the private branch.

Because the branch is hidden from other developers, the user may check in incremental changes to the branch. When the developer is satisfied that his or her changes are completed and ready to be integrated, the developer informs the integrator that all changes on the private branch are ready for integration.

By basing developer private branches off of labels that correspond to the versions used by automated builds, each developer will be able to reuse most of the build results in the form of winked-in derived objects. This significantly reduces the amount of building that is required by each developer when changes are made.

11. Integration Process

Each development activity must eventually be merged into the integration branch. ClearCase has several tools available for performing such a merge. The cleartool findmerge command can be used to merge all changes from a branch onto another branch. From the integrator view, the following command syntax can be used:

 cleartool findmerge dev -all -fversion .../paulz_timing/LATEST -merge

Alternately, Windows NT users can use the ClearCase Merge Manager to perform the same merge.

Both of these methods will merge directory versions and also use Rose RealTime Model Integrator to merge changes in model files. After performing the merge, the integrator should load the model into Rose RealTime and verify that no merge errors have occurred. If the model loads correctly, the changes should be checked in using the Tools -> Source Control -> Submit All Changes to Source Control menu item.

To integrate a series of development activities:

1. Load the model from the integrator's view.
2. Perform the merge as detailed above.
3. Use Tools -> Source Control -> Synchronize Entire Model. This will reload all files that have changed in the merge.
4. Make sure that the merged differences are valid.
5. Use Tools -> Source Control -> Submit All Changes to Source Control to accept the changes and check them into source control.
6. Repeat steps 2 through 5 for each activity that needs integration.