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
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
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.
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:
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:
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
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.
Create the integrator view so that the configuration specification appears as follows:
element * CHECKEDOUT
element * /main/LATEST
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
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
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.
To use ClearCase from Rose RealTime, follow these steps:
Control appropriate model elements as units
Create a local work area
Save a model to the work area
Configure the workspace source control
Add the model to source control
Make the default workspace
available to all project members
Use view templates
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.
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.
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.
To enable source control, fill in the appropriate settings described in the source control fundamentals in the Guide
to Team Development, Rational Rose RealTime.
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.
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.
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.
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.
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:
Label the build files.
Perform the build.
When the build completes successfully:
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.
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:
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
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.
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:
Load the model from the integrator's view.
Perform the merge as detailed above.
Use Tools -> Source Control -> Synchronize Entire Model. This will reload all files that have changed
in the merge.
Make sure that the merged differences are valid.
Use Tools -> Source Control -> Submit All Changes to Source Control to accept the changes and check
them into source control.
Repeat steps 2 through 5 for each activity that needs integration.