Tool Mentor: Setting Up Version
Control using Rational Rose RealTime with Rational ClearCase
Purpose
This tool mentor explains how to set up version control using Rational Rose
RealTime with Rational ClearCase.
This section provides links to additional information related to this tool mentor.
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
toolsets, 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:
cleartool lsview
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:
myview \\mymachine\vws\myview.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.
- 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.
Tool Steps
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 options
- Add the model to source control
- Make
the default workspace available to all project members
- Use view templates
- ClearCase entities
- Automate builds
- Developer process
- Integration process
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:
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.
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.
|