Transcript No Slide Title

ClearCase Training
January 2005
Cairo Clearcase Team
Cairo, Egypt
Amr Elhusseiny
IT Manager
Clearcase support at Mentor Graphics

Europe/middle east
Amr Elhusseiny
Asser Sherif

North America
Roger Moore
Richard England
Ahmed Fayek
Cairo-Egypt
2
Cairo IT Team, ClearCase training, July 2004
WV-USA
3
Cairo IT Team, ClearCase training, July 2004
ClearCase Training







General Concepts
Using ClearCase On UNIX
Using ClearCase On Windows
How To work From Home (snapshot)
Build Control
UCM On Unix
UCM On Windows
4
Cairo IT Team, ClearCase training, July 2004
General Concepts

Configuration Management (Concepts and Goals)

Data Storage – VOBs

Meta-Data for Process Control
5
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Configuration Management Concepts


Tracking objects and changes to the objects
Tracking the relationships and changes to the
relationships between objects, Ex:
o
o
o




Unit tests and source
Source and requirements
Documentation and source
Tracking environment information, i.e. the versions of
tools used to build, etc.
Tracking defects forcing changes to requirements,
source, documentation, and tests
Parallel development
Being able to reproduce previous releases exactly
6
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Configuration Management Goals
Improve the Return on Investment by:

Increasing team productivity

Increasing product quality

Managing process quality

Reducing the time to market

Reusing code when applicable
7
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Data Storage – VOB
(Versioned Object Base)





This is the repository where all
objects (and information about
those objects) is stored.
A VOB is made up of a database and
storage pools.
The database contains information
about elements, derived objects,
cleartext, and meta-data).
The storage pools contain the file
system objects for the elements in
the VOB.
An element is a file or directory.
8
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Data Storage – VOB
(Versioned Object Base), Cont.





Cleartext is a cached version of a previously selected
version of an element.
A derived object is an object that was created by either a
clearmake, omake, build or audit.
Meta-data are bits of information that you can associate
with elements.
The storage pools are subdirectories that contain the file
system data for the VOB.
The element source is stored in the s pool, cleartext
in the c pool, and derived objects in the d pool.
9
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Data Storage - Registries
Registries contain information about VOBs and the
way the VOBs data is accessed (a view).
The registries contain typically:

A unique identification number

The object's name

Its storage path

Where the object is accessible (its region)
10
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
VOB Elements (files and directories)



Each element is made up of
versions, which make up the
revision history of the element.
myfile.c was created resulting in
version 0. It was then modified
and checked in, resulting in
version 1. To create version 2, it
was checked out and back in.
All the work was done on the
main branch of the element.
11
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Accessing VOB Data Using a View

A view is a collection of rules or filters applied in a
specific order to produce the specific versions of the
elements that you see.

In different views, the versions of the elements and
the elements that one user will see may not be the
same as what another user will see, even though they
are looking at the same directory structure.

The rules that the view uses are set in the configuration
specification. (most commonly referred to as a config
spec).
12
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Accessing VOB Data Using a View, Cont.
13
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Metadata For Process Control

Labels

Attributes

Branching

Hyperlinks

Element Types

Triggers

Locks
14
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Labels

Identify specific versions of files.

Use labels to mark milestones in project development.
Lock them to prevent elements being added or removed
inappropriately.
Apply labels to “directory elements” if any element in the
directory will have the label applied to it.
Avoid labeling versions on branches that are only version 0.
Follow the corporate naming convention for labels:
— Label names are all uppercase
— Labels use periods and numbers to denote versions




15
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Attributes

Use attributes to mark states in project
development.

Attributes consist of a name and value pair
Example: attribute State has values of "None",
"Working", "Fixed", "Tested", "Verified"


Users can query the VOB database to find
elements with specific attribute and specific value.
16
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Branching





Use branches to monitor how changes affect the source tree.
Using branches properly allows changes to be checked into the
source tree without affecting nightly builds.
Better not allow development to be done on the /main branch,
instead use task branches off the /main branch, and then
developer branches off the task branch.
Only allow the VOB owner, build person, or specifically
designated person to merge to the /main/LATEST once the code
on the branches have been tested by the individual developer.
Using branches this way complements the check in policy.
Lock release or task branches at appropriate times in the
development cycle.
Follow the corporate naming convention for branches.
—
Branch names are all lowercase.
—
Branch names use periods and numbers to denote versions
17
Cairo IT Team, ClearCase training, July 2004
“Using VOBs and Views”
Branches and Parallel Development
/main
0
/enhancements
Branch
/bugs
0
1
1
2
0
/bug104
0
C4
1
Label
1
Merge
2
18
Cairo IT Team, ClearCase training, July 2004
myfile.c
“Using VOBs and Views”
Branches and Parallel Development, Cont.

All elements have at least one branch, /main. Changes
are normally done to the last version of the element
on a specific branch

Changes can be done to other versions than just the
last version on a branch, but the config spec must be
set up properly.

You need to know exactly which version you are
selecting, and therefore which version you will be
branching from.
19
Cairo IT Team, ClearCase training, July 2004
“Using VOBs and Views”
Branches and Parallel Development, Cont.

Using other than the /main branch only affects those
views with config specs that use the alternative
branch allowing changes to be isolated.

Users can define branches to correspond to the work
that they do. For example, the dr123456 branch would
contain all the work done to fix DR123456.

Branches are used to allow multiple developers to
check out the files, modify them, and check the files
back in without affecting other developers
20
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Hyperlinks
Use hyperlinks to show the relationships between objects.
 Use hyperlinks liberally

Show the relationships between:
— Requirements documents and source files
— Source files and tests
— Source files and documentation
— Tests and data files
21
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Hyperlinks, /main
Cont.
/main
0
myfile.c
/bugfix
1
2
myfile.doc
0
0
/bugfix
1
1
QA_LINK -> /vob/project/myfile.doc
@@/main/bugfix/2
0
1
QA_LINK
2
3
A hyperlink is an annotation that depicts a
relationship between two objects
22
Cairo IT Team, ClearCase training, July 2004
QA_LINK <- /vob/project/myfile.c
@@/main/bugfix/1
Mentor Hyperlink Usage


Hyperlinks are usually coupled with triggers on
specific operations to send email to affected team
members when changes occur.
Examples of hyperlink usage are:
Requirements documents and source files
— Requirements documents and tests
— Requirements documents and documentation
— Source files and tests
— Source files and documentation
— Documentation and tests
—
23
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Element Types
Use element types to distinguish between types of elements.
 Predefined types are:
—
—
—
—
—
—

file - stores any data
compressed file - store any data, using the gzip compression
program
text_file - store text using incremental deltas
compressed_text_file - store text, using incremental deltas and
gzip
binary_delta_file - store any data using both gzip and
incremental deltas
directory - compare and merge directory versions
Users can create their own types to differentiate between
source file types, i.e. C_src, C_Inc, Perl_src.
24
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Triggers

Help to monitor processes. Examples: prevent certain
users from performing certain operations.

Use triggers to control the development process

Triggers can execute before or after the specified command
—
—

Verify conditions are met prior to execution
Prevent unauthorized individuals from executing commands
Triggers can execute after the specified command
—
—
Send notifications to concerned project members
Apply meta-data to elements if specified criteria is met
25
Cairo IT Team, ClearCase training, July 2004
Mentor Trigger Usage

Triggers to control the development process, by
firing before and/or after a command. They can
govern the use of the following commands by using
some or all of the examples:
—
rmelem, rmname, rmver

—
Only allow the VOB owner to remove elements, file elements
from directory elements, or element versions.
rmtype, rmhlink, rmmerge


Only allow the VOB owner to remove type definitions
Under no circumstances allow the removal of merge arrows
(hyperlinks of type MERGE).
26
Cairo IT Team, ClearCase training, July 2004
Mentor Trigger Usage, Cont.
—
mkelem, mkbrtype, mklbtype
 At creation time change the ownership and permissions for all
new elements, branch types, element types, and label types to
the VOB owner.
 For elements, force that a hyperlink be created to a
requirements document.
—
mklabel


Only apply labels to the proper files by using the query
language or "mklabel -config".
Lock labels to prevent modification
27
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Locks


Use locks to mark milestones in project development and
to prevent changes to objects.
Locks can be applied to:
—
—
—
—
—


Labels
Elements
Attributes
Branches
Types
Apply locks to directory elements to prevent new elements
from being added.
Avoid locking versions on branches that only contain
version 0.
28
Cairo IT Team, ClearCase training, July 2004
“General Concepts”
Using VOBs and Views

View types and their differences

Using Config specs
29
Cairo IT Team, ClearCase training, July 2004
“Using VOBs and Views”
View Types and Their Differences
VOB
Versioned Object Base
DYNAMIC
VIEW
Config Specs Rules
SNAPSHOT
VIEW
Config Specs Rules
VIEW Files
VIEW Files
30
Cairo IT Team, ClearCase training, July 2004
“Using VOBs and Views”
View Types and Their Differences, Cont.



Views should be treated as disposable items. It is best
to create a view for each task. Only use ClearCase
commands to remove views.
There are two types of views, snapshot and dynamic.
Each view type has different capabilities and
requirements. However, there are similarities as well.
For example, both view types make use of the
configuration specification as a means of controlling
which files that are visible. And, both have view
storage areas and databases to keep track of the files.
31
Cairo IT Team, ClearCase training, July 2004
“Using VOBs and Views”
View Types and Their Differences, Cont.
Snapshot





Local files (no network dependencies)
Increased performance when accessing Unix VOBs from Windows
Files are downloaded from the VOB server to the client as specified in the
config spec.
Are not updated automatically, but can be updated via command line or
graphical user interface.
Can be shared the same way any Windows directory can be shared.
32
Cairo IT Team, ClearCase training, July 2004
“Using VOBs and Views”
View Types and Their Differences, Cont.
Dynamic




Update immediately to potentially see any changes to elements as soon as
the changes are checked in from another view, assuming the view is
configured to see the changes.
Use build avoidance to get matching objects from other views
Both have view storage directory structures that contain a database to
keep track of view private files (elements that are in the view but not in the
VOB and elements that have been checked out or hijacked), and derived
objects produced in the view. The database also contains the group
access list for the view.
View permissions are governed by the umask of the view owner on Unix,
and the ACLs of the view owner on NT.
33
Cairo IT Team, ClearCase training, July 2004
MultiVersion File System
MVFS






Dynamic Views are based on MVFS
MVFS provides read-only files from CC VOB to Dynamic View
without copying files to View
MVFS Supports the Operating System’s file system interface,
same is done by NFS, NTFS, FAT,.. (Native OS File Systems)
Difference: MVFS Understands Versions, it opens the file version
selected by user’s view
Any Application (VI, WORD,..) can retrieve this file version
transparently
MVFS enables Build Auditing (Track what files are opened during
build process)
34
Cairo IT Team, ClearCase training, July 2004
“Using VOBs and Views”
Using Config Specs

Config Spec rules are what views use to determine which
elements will be visible to the user. These rules are applied in the
order specified to every element in the applicable VOBs.

If the first rule does not match, the next is applied and then the
next and so on until a match is found or there are no more rules.

Usage tip:
—
—
Keep the number of config spec rules to an absolute minimum.
Four rules should be adequate for most tasks.
Avoid the unnecessary complexity of adding specific elements or
versions of elements, Instead, use different views for different
tasks.
35
Cairo IT Team, ClearCase training, July 2004
“Using VOBs and Views”
Using Config Specs, Cont.
The syntax for a config spec rule is:
scope




pattern
version selector
[optional clause]
scope, specifies what elements or types of elements the rule is for,
elements, elements that are files, elements that are directories, or
elements that are a user defined type.
pattern, specifies the pathname to use. Generally, wildcards like '*',
'*.c', and '/vobs/myvob/utils*' are used.
version selector, specifies which version of the elements to use.
This can be a specific version like /main/2 or /main/mybranch/3. It
can also be one chosen by a label like CHECKEDOUT or LATEST
or even an attribute like {created_since(yesterday)}.
Config spec can contain comments also. Any line beginning with a
'#' is treated as a comment
36
Cairo IT Team, ClearCase training, July 2004
“Using VOBs and Views”
Using Config Specs, Cont.
Config specs, examples:
element * CHECKEDOUT
element * .../mybranch/latest
element *.c RELEASE_2.0
element * /main/latest -mkbranch mybranch
37
Cairo IT Team, ClearCase training, July 2004
“Using VOBs and Views”
Using Config Specs, Cont.
Config Specs, Special Rules Example:
 mkbranch/end mkbranch: Tells the view that when a
check out affects an element that is selected by the
corresponding rule to make a branch for the element. By
coupling this command with end mkbranch this rule can
affect a subset of the rules in the config spec.

Load: Applies only to snapshot views, and specifies what
paths in a VOB should be included in the view.
38
Cairo IT Team, ClearCase training, July 2004
“Using VOBs and Views”
Using Config Specs, Cont.

Build and test engineers should use something like:
element * LABELNAME

Working on snapshot view:
load /vobs/<VOB_TAG>
element * CHECKEDOUT
element * /main/LATEST

Developers should use something like:
element * CHECKEDOUT
element * .../mybranch/LATEST
element * LABELNAME -mkbranch mybranch
39
Cairo IT Team, ClearCase training, July 2004
Checkout / Checkin Model
VOB
Versioned Object Base
Checkout
DYNAMIC
VIEW
Config Specs Rules
Checkin
VIEW Files
myfile.c
40
Cairo IT Team, ClearCase training, July 2004
File elements are read-only
until they are checked-out
Checkout / Checkin Model, Cont.
Types of Checkouts

Reserved Checkout (Default)
—
—

Ensures that no checkins may be made until the reserved checkout
is checked back in or cancelled
May only be made if no other reserved checkouts exist for the
same branch
Unreserved
—
—
—
Can be made regardless of the status of other checkouts on the
branch
Can be checked in if no reserved checkouts have been made in the
interim, and no other unreserved checkouts have been checked in
Must be merged or discarded if a checkin from another view has
already taken place
41
Cairo IT Team, ClearCase training, July 2004
Checkout / Checkin Model, Cont.
RESERVED Checkout
UNRESERVED Checkout
3
3
Checkout
Checkout
Checkout
R
U
R
3
3
Checkin
4
42
Cairo IT Team, ClearCase training, July 2004
R
Checkin
U
4
This UNRESERVED checkout
must merge before check in
new version 5
Mentor Check In/Out Policies

Check ins:
since the view servers and individual workstations are
not backed up, check ins should be performed daily on
the developer or task branch. Doing this ensures the
changes are in the VOB.

Check outs:
since ClearCase allows you to see the entire file system
without checking out the elements, it is unnecessary to
check elements out to see them. And, it will be easier
to keep track of the changes mentally if elements are
checked out only as needed.
43
Cairo IT Team, ClearCase training, July 2004
Mentor Naming Conventions

Label names:
are all uppercase and use periods to denote versions i.e.
RELEASE_BUILD.4

Branch names:
are all lowercase and use periods to denote versions

View-tags:



are all lowercase and do not use periods
All private branches should follow the convention: a userid
followed by "_pvt" and then a period followed by the
branch version number, i.e., jsmith_pvt.4.
Some project specific conventions can be added for clarity
and convenience for project members.
44
Cairo IT Team, ClearCase training, July 2004
Mentor View Usage

Create one view for each developer to avoid view
registry problems.

Keep the number of config spec rules to an
absolute minimum.
At most, four rules should be adequate for most tasks,
generally fewer will suffice.
— Avoid the unnecessary complexity of adding specific
elements or versions of elements.
—
45
Cairo IT Team, ClearCase training, July 2004
Using ClearCase On UNIX
46
Cairo IT Team, ClearCase training, July 2004
Base Clearcase under Unix
47
Cairo IT Team, ClearCase training, July 2004
Requirements and settings

To start working with Clearcase under Unix you need to do
the following:
—
Log on a machine on which ClearCase client is installed
—
Add /opt/rational/clearcase/bin to your PATH
and /opt/rational/clearcase/doc/man to your MANPATH
—
Adjust your umask to a suitable permissions for you and your
group ( e.g. umask 2 )
48
Cairo IT Team, ClearCase training, July 2004
Umask


umask command is used to get or set the file mode creation
mask
An example of the output produced by 'ls -l' is shown
below:
drwx------ 2
drwxrws--- 2
-rw-rw---- 2
drwxr-xr-x 3


richard
richard
richard
richard
staff
staff
staff
user
2048 Jan 2 1997 private
2048 Jan 2 1997 admin
12040 Aug 20 1996 userinfo
2048 May 13 09:27 public
In most cases the default Umask settings is ‘022' and can
be checked by typing “umask” at the command prompt
This default setting produces permissions of “755” for files
and directories creation:
-rwxr-xr-x for regular files
drwxr-xr-x for directories
49
Cairo IT Team, ClearCase training, July 2004
Umask cont…..


To change the umask use the command “umask #” at the
command prompt, where # represents the new umask you
want to use
For example, use the command “umask 2” to create files
and directories with permissions “775”:
-rwxrwxr-x for regular files
drwxrwxr-x for directories
50
Cairo IT Team, ClearCase training, July 2004
Find Your Way

List all VOBs
> cleartool lsvob
* /vobs/TNT_pfgen
/net/egccc1/export/vobs/vobstore/TNT_pfgen.vbs public
* /vobs/IT_VOB
/net/egccc1/export/vobs/vobstore/IT_VOB.vbs public
/vobs/icx_software /net/egccc1/export/vobs/vobstore/icx_software.vbs public
* Denotes VOBs mounted on current ClearCase client.

List all VIEWs
> cleartool lsview
* amre_TNT_vu /net/egccc1/export/vobs/views/username_TNT_sco_vu.vws
assers_develop_vu /net/egccc1/export/vobs/views/mselim_develop_vu.vws
* Denotes VIEWs currently in use.
51
Cairo IT Team, ClearCase training, July 2004
Create your Dynamic UNIX VIEW

Storage location plkviews already created on the filer CHOPIN for
hosting the dynamic views for UNIX
> umask 2 ( to set permissions to 775 if required)
> cleartool mkview -tag your_view_tag –stgloc plkviews
Created view.
Host-local path: chopin:/vol/vol2/plkviews/your_view_tag.vws
Global path: /net/chopin/vol/vol2/plkviews/ your_view_tag.vws
It has the following rights:
User : username
: rwx
Group: plk : rwx
Other:
: r-x
52
Cairo IT Team, ClearCase training, July 2004
Create your Snapshot Unix View

For each user’s machine, a storage location needs to be created by
the CC support team, the standard naming is:
machine-name_team-name_viewstore

A scratch area on the machine where the storage location is
created needs to be shared so that it can be accessed from the path
/net/machine-name/scratch-area
53
Cairo IT Team, ClearCase training, July 2004
Create your Snapshot Unix View

To create the snapshot view in the storage location created in the
scratch area on your local machine use:
>cleartool mkview –tag your_view_tag -snap –stg storage_location_name \
/net/your_machine_name/path_to_your_scratch_area/your_View_Tag

Example:
> cleartool mkview –tag amre_test_vu –snap –stg md8_IT_viewstore
/net/md8/export/home/users/amre/views/amre_test_vu
54
Cairo IT Team, ClearCase training, July 2004
Working with Dynamic Views

Set a dynamic view to be your current VIEW
>cleartool setview your_view_tag

Print your current dynamic VIEW
>cleartool pwv
Working directory view: ** NONE **
Set view: your_view_tag
NEVER remove the view using UNIX
command rm –rf
55
Cairo IT Team, ClearCase training, July 2004
Config Spec – Dynamic View

View your configuration specs
>cleartool catcs
element * CHECKEDOUT
element * /main/LATEST

Edit your configuration Specs
>cleartool edcs
element * CHECKEDOUT
element * /main/LATEST
Set config spec for view “view-tag” ? [Yes]

Set configuration Specs file
>cleartool setcs file_name
56
Cairo IT Team, ClearCase training, July 2004
Working with Snapshot Views

To set a Snapshot view to be your current view all
you need to do is to CD to the path of the snapshot
view you created, example:
> cd /net/md8/export/home/users/amre/views/amre_test_vu

Next thing you need to do is to load the needed
directories and files from the VOB
57
Cairo IT Team, ClearCase training, July 2004
Adding or Modifying Load Rules
You can add or modify load rules in any of the following ways:


Any time you edit and modify a snapshot view’s config
spec, ClearCase updates the entire view. This is appropriate
when you first create a view, or when you modify a view’s
version-selection rules, but it may be cumbersome if you
only want to add a few elements to the view
By using update –add_loadrules. The –add_loadrules
option of cleartool update adds load rules to your view’s
config spec but updates only the portion of the view that is
affected by the new load rules
58
Cairo IT Team, ClearCase training, July 2004
Add Load Rules When Editing the Config Spec

Open the view’s config spec for editing by doing the following:
—
—
Open a shell and change to a directory in the view (Where the elements will
be loaded from VOB).
Use the following command to edit the config spec file:
> cleartool edcs
ClearCase opens the view’s config spec in your default text editor

In your text editor, use the following syntax to create load rules:
load vob-tag/element-pathname
For example, the rule load /vobs/testvob loads all files and directories in the
VOB named /vobs/testvob.
The rule load /vobs/testvob/batch loads only the batch directory recursively.

Save the config spec and exit the text editor.

In your shell, answer Yes at the ClearCase prompt for setting the config
spec.
59
Cairo IT Team, ClearCase training, July 2004
Add Load Rules with update –add_loadrules

Use the following command:
> cleartool update –add_loadrules element-pathname
Where, element-pname: names an element in the VOB namespace at a pathname that
is relative to a snapshot view.

For example, the following command loads all elements in a VOB named /guivob
into the view pat_v1.4_cropcircle_sv:
> cleartool update –add_loadrules ~/pat_v1.4_cropcircle_sv/guivob

You can also use a relative pathname for the element-pathname argument. For
example, these commands load all elements in the vob guivob:
> cd ~/pat_v1.4_cropcircle_sv
> cleartool update –add_loadrules guivob

These commands load only the batch directory recursively:
> cd ~/pat_v1.4_cropcircle_sv
> cleartool update –add_loadrules guivob/batch
60
Cairo IT Team, ClearCase training, July 2004
Excluding Elements from Loading

ClearCase loads all directory elements recursively. To exclude some elements from
loading, you can use an element rule in the config spec that selects an element’s
initial version. For all ClearCase elements, the initial version contains no data..
To Exclude Elements you have to open the view’s config spec for editing
— Open a shell and change to a directory in the view
— Use the command
> cleartool edcs
— In the text editor, create an element rule that specifies the initial version of the
element you want to exclude by using the following syntax:
element vob-tag/element-pathname /main/0

For example, the element rule element /guivob/interface /main/0 loads the empty
version of the interface directory in /guivob, preventing any of its child elements from
loading.

Save the config spec and exit the text editor.

In your shell, answer Yes at the ClearCase prompt for setting the config spec.

61
Cairo IT Team, ClearCase training, July 2004
Updating a Snapshot View

The rules in your view’s config spec are usually designed to
select a discrete set of versions from the VOB. For example,
your view is usually intended to contain a set of versions
that build successfully. However, when other developers
check in new versions from their views, a snapshot view
may become out of date or inconsistent with the versions in
the VOB

To make sure that your view contains the set of versions
the config spec selects, you must update it

An update operation copies versions of elements from a
VOB to your view. Only the checkin operation copies
changes from your view back to a VOB
62
Cairo IT Team, ClearCase training, July 2004
Updating the View

You can start an update operation for:
—
—

The entire view
At least one file or at least one directory tree
To update the view, use cleartool update with any of the following
options:
> cleartool update command-options snapshot-view-pathname

The snapshot-view-pathname argument is optional if you enter the
update command from the root directory of the view

For a description of all available command options, see the update
reference page in the Command Reference
63
Cairo IT Team, ClearCase training, July 2004
Updating the View

For example:
> cleartool update ~/pat_1.4_cropcircle_sv

NOTE: You can use the Update Tool to update the view instead of
the command line. To start the update GUI, use the following
command:
> cleartool update –graphical snapshot-view-pathname
64
Cairo IT Team, ClearCase training, July 2004
Updating Files and Directory Trees

To save time, you can update individual files or directories.
(Rational ClearCase updates directories recursively.) Updating
only specific parts of your view may eventually cause the view to
contain an inconsistent set of versions
Use the following command:
> cleartool update command_options pathnames-of-loaded-elements

NOTE: You cannot update a checked-out file. To undo changes to
a checked-out file and start over with the version in the VOB,
cancel the checkout
65
Cairo IT Team, ClearCase training, July 2004
Unloading Elements


If a view’s config spec no longer selects an element,
ClearCase removes, or unloads, it from the view. Unloading
does not affect view-private files or view-private directories
Updating can cause an element to be unloaded from a view
in the following situations:
—
—
You remove the load rule that specifies the element (or that specifies a
directory element somewhere above it)
The version-selection rules no longer select any version of the element.
This can happen when your config spec selects a version of the parent
directory that no longer contains a version of the file element
66
Cairo IT Team, ClearCase training, July 2004
Unloading Files

The action that ClearCase takes to unload a file
depends on the file’s current state:
—
For a file that is not checked out, ClearCase deletes the
file from the view
—
For a hijacked file, ClearCase appends .unloaded to the
file name, unless you use update –overwrite to delete
hijacked files
—
For a checked-out file, ClearCase appends .unloaded to
the file name. The version remains checked out to your
view
67
Cairo IT Team, ClearCase training, July 2004
Unloading Directories

ClearCase unloads directories recursively. To unload
a directory element, ClearCase unloads the files in the
directory. If any view-private objects, hijacked files, or
checked-out files are in the directory, or if the
directory is currently in use (for example, if your
current working directory is in or below the directory)
ClearCase appends .unloaded to the name of the
directory

For example, if the directory src contains view-private
files, ClearCase renames the directory to
src.unloaded
68
Cairo IT Team, ClearCase training, July 2004
Working in a Snapshot View Without the Network
(Laptop)

If you need to work with your source files from a computer
that is disconnected from the network of Rational
ClearCase hosts and servers, you can set up a snapshot
view for disconnected use

This includes the following tasks:
—
—
—
—
—
—
Setting up a view
Preparing the view
Disconnecting the view
Working in the view
Reconnecting to the network
Using the Update Tool
69
Cairo IT Team, ClearCase training, July 2004
Working in a Snapshot View Without the Network
(Laptop)

While on network:
—
—
—

Disconnect from Network:
—
—

Update the view from the VOB
Check out the files you intend to work on offline
Deactivate clearcase integrations
Use windows explorer to modify the checked out files in the snapshot view
location
If you want to modify non-checkedout files, there is a way to do so and they
are considered hijacked
Connect to network:
—
—
—
—
Reactivate clearcase integrations
Find the files modified while disconnected and also hijacked files
Check in all files to the VOB
Update your view from the VOB with any changes done on VOB while you
were offline
70
Cairo IT Team, ClearCase training, July 2004
Working with Vobs

List files in a VOB
>ls
file_name
archive
db
test_data
test_log
version
>cleartool ls
file_name@@/main/1
archive@@/main/1
db@@/main/1
test_data@@/main/1
test_log@@/main/1
version@@/main/4
Rule:
Rule:
Rule:
Rule:
Rule:
Rule:
/main/LATEST
/main/LATEST
/main/LATEST
/main/LATEST
/main/LATEST
/main/LATEST
>cleartool ls -long
version
directory
directory
directory
directory
version
version
version
version
version
file_name@@/main/1
archive@@/main/1
db@@/main/1
test_data@@/main/1
test_log@@/main/1
version@@/main/4
71
Cairo IT Team, ClearCase training, July 2004
Rule:
Rule:
Rule:
Rule:
Rule:
Rule:
element
element
element
element
element
element
*
*
*
*
*
*
/main/LATEST
/main/LATEST
/main/LATEST
/main/LATEST
/main/LATEST
/main/LATEST
Working with Vobs..Cont

List version of a file in a VOB
>cleartool lsvtree file_name
file_name@@/main
file_name@@/main/4
>cleartool lsvtree –all file_name
file_name@@/main
file_name@@/main/0
file_name@@/main/1
file_name@@/main/2
file_name@@/main/3
file_name@@/main/4
72
Cairo IT Team, ClearCase training, July 2004
Working with Vobs..Cont

View different versions of a file in a VOB
>cat file_name@@/main/3
>cat file_name@@/REL2
>cat file_name@@/main/LATEST
73
Cairo IT Team, ClearCase training, July 2004
Checkout / Checkin Files

Checkout a file
>cleartool checkout myfile.c
Checkout comments for “myfile.c”
Fix Bug 102.
.
Checked out “myfile.c” from version “/main/3”.

List Checked out files
>cleartool lscheckout –me
>cleartool lscheckout –cview
>cleartool lscheckout –all
74
Cairo IT Team, ClearCase training, July 2004
(By current login)
(In current VIEW)
(All files in VOB)
Checkout / Checkin Files

Checkin a file
>cleartool checkin –c “Fix Bug 103” myfile.c
Checked in “myfile.c” version “/main/4”.

Cancel Checkout of a file
>cleartool uncheckout myfile.c
Save private copy of “myfile.c"? [yes] no
Checkout cancelled for “myfile.c”.
75
Cairo IT Team, ClearCase training, July 2004
Creating new elements

Add new directory to a VOB
> cleartool mkdir doc
Creation comments for “doc”:
New directory for documentation
.
Created directory element “doc”.
Checked out “doc” from version “/main/0”.

Add new element to a VOB
> cleartool mkelem document1.txt
Creation comments for “document1.txt”:
New document
.
Created element “document1.txt” (type “text_file”)
Checked out “document1.txt” from version “/main/0”.
76
Cairo IT Team, ClearCase training, July 2004
Metadata for Process Control
Labels
Attributes
Branching
Merging
Hyperlinks
Element
Types
Triggers
77
Cairo IT Team, ClearCase training, July 2004
Labels

Declare new label type
>cleartool mklbtype –c “Release2” REL2
Created label type “REL2” .

List Label types declared
>cleartool lstype -kind lbtype
05-Sep.15:49
plkvobadm
label type "CHECKEDOUT"
"Predefined label type used to represent checked out
versions."
30-Jun.16:46
plkvobadm
label type "REL2"
“Release2"

Label a file
>cleartool mklabel REL2 myfile.c
Created label “REL2” on “myfile.c” version “/main/4”
78
Cairo IT Team, ClearCase training, July 2004
Attributes

Declare attribute type
>cleartool mkattype –c “Sample Attribute” Project
>cleartool mkattype –c “Sample Metric Attribute” \
–vtype integer –gt 0 –le 10 -default 1 Metric_Attribute
>cleartool mkattype –c “Development stages” \
-enum /”development/”,/”integration/”, /”released/”
Stage
Attributes can be attached to an element, a branch, a specific version
or even hyperlinks and symbolic links and their usage can be
restricted to specific branch, version by –vpbranch , -vpversion
switches
79
Cairo IT Team, ClearCase training, July 2004
Attributes

Attach attribute/value pair to a file/version/branch
>cleartool mkattr –ver /main/3 Metric_Attribute 6 myfile.c
Created attribute “Metric_Attribute” on “myfile.c@@/main/3”

Replace existing attributes
>cleartool mkattr
Created attribute
Created attribute
Created attribute
Created attribute

–config hello.exe –replace qa_tested /”waiting/”
“qa_tested” on “/project/@@/main/3”
“qa_tested” on “/project/src/@@/main/2”
“qa_tested” on “/project/src/myfile.c@@/main/2”
“qa_tested” on “/project/src/myfile.h@@/main/2”
Remove attribute instance
>cleartool rmattr Stage myfile.c
80
Cairo IT Team, ClearCase training, July 2004
Branching

Declare new branch type
>cleartool mkbrtype –c “Bug Fixes” rel2_bugs
Created branch type “rel2_bugs” .

List branch types
>cleartool lstype -kind brtype
05-Sep.15:49
plkvobadm branch type "main"
"Predefined branch type used to represent the main
branch of elements."
30-Jun.16:20
plkvobadm branch type “rel2_bugs“
"Bug Fixes"
81
Cairo IT Team, ClearCase training, July 2004
Branching

Branch a file
>cleartool mkbranch rel2_bugs myfile.c
Creation comments for “myfile.c@@/main/rel2_bugs":
Bug Fix Branch
.
Created branch "rel2_bugs" from “myfile.c" version
"/main/4".
cleartool: Warning: Version checked out
("/main/rel2_bugs/0") is different from version
selected by view before checkout ("/main/4").*
Checked out “myfile.c" from version
"/main/rel2_bugs/0".
* You need to set your configuration specs to the new branch rel2_bugs
82
Cairo IT Team, ClearCase training, July 2004
Branching

Configuration specs could be set to view a specific
branch of an element, or create this branch if it
doesn’t exist when checked out.
element * CHECKEDOUT
element * …/rel2_bugfix/LATEST
element * /main/LATEST –mkbranch rel2_bugfix
83
Cairo IT Team, ClearCase training, July 2004
Merging

Merge Algebra
base
A
contrib 1
A
B
A
deleted
C
D
D
E
Q
contrib 2
A
B
deleted
inserted
changed
84
Cairo IT Team, ClearCase training, July 2004
merge result
C
inserted
Z
changed
Z
changed
F
changed
?
conflict
Merging
/main
0
/bugs
A common merge practice
Branch
0
1
Merge from bugs branch to
the main branch of the file
2
3
85
Cairo IT Team, ClearCase training, July 2004
1
Merge
Merging
>cleartool co myfile.c@@/main/LATEST
Checkout comments for "myfile.c":
.
cleartool: Warning: Version checked out
("/main/3") is different from version selected
by view before checkout ("/main/bugs/1").
Checked out "myfile.c" from version "/main/3".
>cleartool catcs
element * CHECKEDOUT
element * /main/bugs/LATEST
element * /main/LATEST
86
Cairo IT Team, ClearCase training, July 2004
Merging
cleartool merge -to myfile.c -ver /main/bugs/LATEST
<<< file 1: /vobs/TNT_pfgen/pfgen/myfile.c@@/main/1
>>> file 2: /vobs/TNT_pfgen/pfgen/myfile.c@@/main/bugs/1
>>> file 3: myfile.c
--------[after 11 file 1]----------|------[inserted 12-13 file 2]-----|
| Added in Branch bugs
|--------[after 11 file 1]----------|-------[inserted 12-15 file 3]-----|
| added version 3
|Do you want the INSERTION made in file 2? [yes] y
Applying INSERT from file 2 [lines 12-13]
Do you want the INSERTION made in file 3? [no] y
Applying INSERT from file 3 [lines 12-15]
Moved contributor "myfile.c" to "myfile.c.contrib.1".
Output of merge is in "myfile.c".
Recorded merge of "myfile.c".
87
Cairo IT Team, ClearCase training, July 2004
Merging
>cleartool describe myfile.c
version "myfile.c@@/main/CHECKEDOUT" from /main/3
(reserved)
checked out 12-Jul-02.11:50:28 by username
(username.plk@plkvob)
by view: username_vu
(“plkview:/dsk3/views/username_vu.vws")
Element Protection:
User : username
: rwx
Group: plk
: rwx
Other:
: r-x
element type: text_file
predecessor version: /main/3
Hyperlinks:
Merge <- /vobs/plk_IT_basetrain/myfile.c@@/main/bugs/1
88
Cairo IT Team, ClearCase training, July 2004
Merging
>cleartool checkin -nc myfile.c
cleartool: Warning: Version checked in is not
selected by view.
Checked in "myfile.c" version "/main/4".
89
Cairo IT Team, ClearCase training, July 2004
Hyperlinks
/main
0
/main
myfile.c
/bugfix
1
2
myfile.doc
0
0
/bugfix
1
1
QA_LINK -> /vob/project/myfile.doc
@@/main/bugfix/2
0
1
QA_LINK
2
3
A hyperlink is an annotation that depicts a
relationship between two objects
90
Cairo IT Team, ClearCase training, July 2004
QA_LINK <- /vob/project/myfile.c
@@/main/bugfix/1
Hyperlinks

Create hyperlink type
>cleartool
mkhltype –c “Sample hyperlink”
TESTED
Created hyperlink type “TESTED”.

Attach hyperlink instance. It can be attached to
element, version or branch.
>cleartool
mkhlink TESTED myfile.c myfile.doc
Created hyperlink
“TESTED@102@/vob/plk_IT_basetrain”.
91
Cairo IT Team, ClearCase training, July 2004
Hyperlinks

Search for a hyperlink
>cleartool find . –version ’hltype(TESTED)’ -print
./myfile.c@@/main/3
./myfile.doc@@/main/1
>cleartool find . –version ’hltype(TESTED,->)’ -print
./myfile.c@@/main/3
>cleartool find . –version ’hltype(TESTED,<-)’ -print
./myfile.doc@@/main/1
92
Cairo IT Team, ClearCase training, July 2004
Element Types

Create new subtype of ‘text_file’ type
>cleartool mkeltype –supertype text_file –c “VHDL
source file” vhdl_source
Created element type “vhdl_source”.

Create new element of predefined type
>cleartool mkelem –nc
and2.vhd
Created element “and2.vhd” (type “vhdl_source”).
Checked out “and2.vhd” from version “/main/0”

Create new element of undefined type
>cleartool mkelem –eltype text_file and2.abc
Created element “and2.abc” (type “text_file”).
Checked out “and2.abc” from version “/main/0”
93
Cairo IT Team, ClearCase training, July 2004
Element Types

Change existing element types
>cleartool chtype vhdl_source and2.vhd nand2.vhd
Changed type of element “and2.vhd” to vhdl_source.
Changed type of element “nand2.vhd” to vhdl_source.

Element types and file-typing rules are stored in magic
files (default magic file is at
/usr/atria/config/magic/default.magic)

A user can create his/her own magic file
(<anyname>.magic) and point the environmental
variable MAGIC_PATH to it.
94
Cairo IT Team, ClearCase training, July 2004
Element Types

Sample of Magic file contents :
doc_file compressed_file : -name "*.[dD][oO][cC]" ;
ms_excel ms_office compressed_file : -name "*.[xX][lL][sS]" ;
csh_script script text_file : -printable & -magic 0, "#!" & token "csh" ;
ksh_script script text_file : -printable & -magic 0, "#!" & token "ksh" ;
pdf compressed_file : -name "*.[pP][dD][fF]" ;
95
Cairo IT Team, ClearCase training, July 2004
Triggers

Use triggers to control the development process

Triggers can execute before or after the specified
command
—
—

Verify conditions are met prior to execution
Prevent unauthorized individuals from executing commands
Triggers can execute after the specified command
—
—
Send notifications to concerned project members
Apply meta-data to elements if specified criteria is met
96
Cairo IT Team, ClearCase training, July 2004
Build Control






Build tools
Additional features in clearmake
Derived Objects
Configuration Records
Manipulating Derived Objects
Parallel and Distributed Builds
97
Cairo IT Team, ClearCase training, July 2004
Build Tools


Clearmake:
— the main tool used with Unix
Omake:
— another tool used on Windows that can be
integrated with Developer's Studio as a
replacement to its default compiler. clearmake
exists on Windows also
98
Cairo IT Team, ClearCase training, July 2004
Additional Features in clearmake






Build auditing -- a complete “bill of material”
Automatic detection of source dependencies including
header file dependencies
Build avoidance algorithm -- guarantees correct results
in a parallel development environment
Binary sharing among developers
Compatibility modes -- use clearmake with makefiles
constructed for other make variants
Parallel and distributed building in a heterogeneous
environment
99
Cairo IT Team, ClearCase training, July 2004
Derived Objects


A derived object (DO) is any file created
within a VOB by a build script
Each DO consists of a :
File name and VOB directory
— Derived object identifier (DO-ID)
 Hello@@24-Feb.16:40.134
— Data container
— Configuration record (CR)
— VOB database catalog for shareable DOs
—
100
Cairo IT Team, ClearCase training, July 2004
Derived Objects

List derived objects :
>cleartool lsdo –long
23-Aug-02.12:14:23
username
(username.sysadmin@plkvob)
create derived object "reg_model.exe@@23-Aug.12:14.651"
size of derived object is: 488287
last access: 23-Aug-02.12:14:23
references: 1 =>
plkview:/net/plkview/views/username_regmodel_vu.vws
101
Cairo IT Team, ClearCase training, July 2004
Configuration Records

View configuration records (CR) :
>cleartool catcr reg_model.exe
Target exec built by username.sysadmin
Host “plkview" running SunOS 5.8 (sun4u)
Reference Time 23-Aug-02.12:11:12, this audit started 23-Aug-02.12:13:38
View was plkview:/net/plkview/views/username_regmodel_vu.vws
Initial working directory was /vobs/plk_IT_basetrain/regmodel/ss6
---------------------------MVFS objects:
---------------------------/vobs/plk_IT_basetrain/regmodel/src/glue/Makefile@@/main/1 <06-Jun02.10:08:48>
/vobs/plk_IT_basetrain/regmodel/src/glue/overrides.mk@@/main/1 <02-Jul99.01:35:08>
/vobs/plk_IT_basetrain/regmodel/src/glue/overrides.ss6.mk@@/main/1 <02Aug-00.00:25:23>
…
102
Cairo IT Team, ClearCase training, July 2004
Configuration Records
---------------------------Variables and Options:
---------------------------GMAKE_PARALLEL=
MAKE=/opt/rational/clearcase/bin/clearmake
MAKEFLAGS=
PATH_MGC=/usr/devmgc
---------------------------Build Script:
---------------------------…
/opt/rational/clearcase/bin/clearmake -w exec ;
/usr/devmgc/lib/mgcms/do_exports glue/exports.exec exports
----------------------------
103
Cairo IT Team, ClearCase training, July 2004
Configuration Records

Comparing config records
>cleartool diffcr regmodel.exe regmodel.exe@@31Oct.07:25.304
Differences detected:
—
—
—
—
—
—
Versions of MVFS objects used as sources
Objects produced during the build
Versions of non-MVFS objects that appeared as makefile
dependencies
The number of times an object was referenced during the
build, and the first target in which that object was referenced
Build options
The build script executed
104
Cairo IT Team, ClearCase training, July 2004
Manipulating Derived Objects

Unshared derived objects (produced in express
build) can be promoted to the VOB database to be
used by other views via Winkin process, e.g.
>cleartool winkin DO-pname

To preserve configuration records (CR) of the
derived object (DO) during checking in the DO,
you have to checkin to its place in the VOB. You
can use –from switch if the DO is created in
another directory, e.g.
>cleartool checkin –c “Beta 2 Build” –from ./hello
../bin/hello
105
Cairo IT Team, ClearCase training, July 2004
Manipulating Derived Objects

view_scrubber is used to remove derived objects
data containers as long as they are checked in the
VOB. It can be used also to convert DOs to
shareable or promote these DOs. It can be found at
/opt/rational/clearcase/etc/view_scrubber
106
Cairo IT Team, ClearCase training, July 2004
Using ClearCase On Windows
107
Cairo IT Team, ClearCase training, July 2004
Requirements and Settings
•User Environment variables (not SYSTEM variables):
•CCASE_BLD_UMASK 002
•CLEARCASE_PRIMARY_GROUP  plk
(User’s Primary Group in Active Directory)
- Control Panel  ClearCase  Options, choose the Domain  MGC
- You may need to restart your PC after ClearCase installation to confirm
Clearcase services are up using MGC\clearcase_albd Account:
- Control Panel  Administrative Tools  Services  Atria Location Broker:
This service should be Automatically Up with “Log On As”
MGC\clearcase_albd
108
Cairo IT Team, ClearCase training, July 2004
How To share The View Location
The View Location on the PC should be shared (Full Control) for both:
1- User’s
MGC Account
2- MGC\clearcase_albd



Account
From “My Computer”, On the Partition where you have the
largest free space (Ex: E ), Create a new folder: cc_views
Right Click on the folder, Choose “Sharing And Security..”,
Choose “Share This Folder”, Share Name: cc_views,
Click on “Permissions” button, Click on “Add” button, Type
your login name, check it and add it, then type
“clearcase_albd”, check it and add it.
For both accounts choose “Full Control” in the lower part of
the share permissions tab, then click OK to accept the
settings.
109
Cairo IT Team, ClearCase training, July 2004
ClearCase Program menu
110
Cairo IT Team, ClearCase training, July 2004
ClearCase Home Base User Interface
111
Cairo IT Team, ClearCase training, July 2004
ClearCase Properties
112
Cairo IT Team, ClearCase training, July 2004
Make Sure CC Is Running
113
Cairo IT Team, ClearCase training, July 2004
Stopping CC
If ClearCase
Cannot be
stopped/restarted,
you have to
restart your PC.
114
Cairo IT Team, ClearCase training, July 2004
ClearCase Properties
115
Cairo IT Team, ClearCase training, July 2004
Create View
116
Cairo IT Team, ClearCase training, July 2004
Create View, Cont.
117
Cairo IT Team, ClearCase training, July 2004
Create Dynamic View
118
Cairo IT Team, ClearCase training, July 2004
Create Dynamic View, Cont.
The Mapped Drive
Letter could be any
free mapping Letter.
Ex: Z, Y, X, ….
Check Network
Drives in “My
Computer” Or
“Windows Explorer”
119
Cairo IT Team, ClearCase training, July 2004
loginname_vu
Create Dynamic View, Cont.
Advanced Options
\\machine\cc_views\MGC\loginname\loginname_vu.vws
plk_nt
120
Cairo IT Team, ClearCase training, July 2004
Create Dynamic View, Cont.
loginname_vu
121
Cairo IT Team, ClearCase training, July 2004
Create Dynamic View, Cont.
loginname_vu
122
Cairo IT Team, ClearCase training, July 2004
Create Snapshot View
123
Cairo IT Team, ClearCase training, July 2004
Create Snapshot View, Cont.
E:\cc_views\MGC\loginname\loginname_snap_vu
124
Cairo IT Team, ClearCase training, July 2004
Create Snapshot View, Cont.
Advanced Options
E:\cc_views\MGC\loginname\loginname_snap_vu.vws
loginname_snap_vu
125
Cairo IT Team, ClearCase training, July 2004
Create Snapshot View, Cont.
E:\cc_views\MGC\loginname\loginname_snap_vu
126
Cairo IT Team, ClearCase training, July 2004
Create Snapshot View, Cont.
Select VOBs/Elements To Load
127
Cairo IT Team, ClearCase training, July 2004
Create Snapshot View, Cont.
128
Cairo IT Team, ClearCase training, July 2004
Create Snapshot View, Cont.
loginname_snap_vu
129
Cairo IT Team, ClearCase training, July 2004
Updating Snapshot View
130
Cairo IT Team, ClearCase training, July 2004
Remove View
131
Cairo IT Team, ClearCase training, July 2004
Remove View, Cont.
132
Cairo IT Team, ClearCase training, July 2004
Remove View, Cont.
133
Cairo IT Team, ClearCase training, July 2004
Remove View, Cont.
test_tmp_vu
134
Cairo IT Team, ClearCase training, July 2004
ClearCase Doctor
135
Cairo IT Team, ClearCase training, July 2004
Context Sensitive Menus
136
Cairo IT Team, ClearCase training, July 2004
Mounting VOBs
137
Cairo IT Team, ClearCase training, July 2004
Compare Versions
Comparing with
Previous Version is not
always successful. It
depends on the file
type. Ex: It Can’t be
done with MS Project
.mpp files and certain
MS Word versions.
138
Cairo IT Team, ClearCase training, July 2004
Element Properties
139
Cairo IT Team, ClearCase training, July 2004
Version Tree Browser
140
Cairo IT Team, ClearCase training, July 2004
Version Tree Browser, Cont.
141
Cairo IT Team, ClearCase training, July 2004
UCM On UNIX
142
Cairo IT Team, ClearCase training, July 2004
Using Unified Change
Management ClearCase
General concept &
UNIX
Unified Change Management










Pros and Cons
UCM Workflow
Roles and Responsibilities
UCM Terminology
Setting Up Working Areas
Finding and Setting Activities
Working on Activities
Delivering Activities
Rebasing your Work Area
Sample GUI scenario
144
Cairo IT Team, ClearCase training, July 2004
Pros and Cons

Pros
— Provides an out of box solution enabling groups to work on product
development, not customizations.
— Automatically manages artifacts and work in progress.





—
—
—
Config specs are managed by the software, not the developer.
Artifacts are tracked by "activities", allowing the user to more readily
identify the work done for specific tasks.
Activities can be more easily prioritized because of the way they are
identified.
Work loads and critical paths can be identified more easily too.
Generic reporting capabilities are included in the system.
Work is done in isolation to not impact others. Users choose when to
make changes available to others.
Work on specified tasks can be tracked easily during the entire
software lifecycle.
Should be good for teams without well defined software development
processes.
145
Cairo IT Team, ClearCase training, July 2004
Pros and Cons

Cons
— Can be customized, but provides a fairly rigid methodology that
must be followed.
— Though it is based on many years of development and many
customers' usage models, the UCM features are recent
enhancements to ClearCase (1999).
— Sharing data between projects is constrained, administrative
guidelines must be followed. Components can be controlled by only
ONE PVOB.
146
Cairo IT Team, ClearCase training, July 2004
UCM Workflow
147
Cairo IT Team, ClearCase training, July 2004
UCM Workflow
- Join UCM Project.
- Create 2 work areas :
- Private area for working in isolation in activities
- Shared area for testing activities delivered
148
Cairo IT Team, ClearCase training, July 2004
UCM Workflow
- Use cleartool lsactivity to list activities in your work area.
- Setting your view to an activity instructs ClearCase to assign any
versions of source files you create to the activity’s change set. You
must set your view to an activity before you can work on an activity.
149
Cairo IT Team, ClearCase training, July 2004
UCM Workflow
- Checkout files to be writable for developer.
- View / Modify Metadata to describe changes.
- Checkin changes.
- Indicate progress either by ClearQuest or by specific schema.
150
Cairo IT Team, ClearCase training, July 2004
UCM Workflow
- Prepare work areas if they are older than current integration.
- Start deliver operation
- Merge changes between private work area and shared integration
area.
- Build and Test integration.
- Finish delivery and ClearCase will check in modifications.
151
Cairo IT Team, ClearCase training, July 2004
UCM Workflow
- Integrator organizes delivered activities into baselines. When a
baseline reaches stable level after testing, your integrator
designates it as a recommended baseline.
- To work with the set of versions in the recommended baseline,
you rebase your development work area. You will need to merge
this new baseline with your private area, test and complete rebase
operation.
152
Cairo IT Team, ClearCase training, July 2004
Roles and Responsibilities

Project manager
—
—
—

Architect
—

Allocates components and activities for the project
Determines initial milestones (baselines)
Specifies the project's policies and tasks
Translates project architecture into directory structure
Administrator
—
Creates and maintains the infrastructure
153
Cairo IT Team, ClearCase training, July 2004
Roles and Responsibilities

Developer
—
—
—
—

Creates and modifies project activities
Builds and tests changes
Delivers changes to the integration area
Manages personal work areas
Integrator
—
—
—
Integrates changes from developers into the project's integration
work space
Builds and tests changes
Creates new baselines
154
Cairo IT Team, ClearCase training, July 2004
UCM Terminology

Elements
—

Components
—

Files and directories put under version control of Clearcase.
Elements are organized as components. Usually, components can
be built into functional units of software.
Baselines
—
To keep track of different
configurations of versions,
your project manager or
integrator creates a baseline, which records one
version of each element in
a component. In effect, a baseline is a version of a component.
155
Cairo IT Team, ClearCase training, July 2004
UCM Terminology

Activities
—

To create a version in a ClearCase
UCM project, you must first assign
it to an activity. An activity is a
ClearCase object that identifies the
versions created to complete a task.
Streams
—
A stream is a long-lived ClearCase
object. It is a member of a single
UCM project and is a mechanism
for creating and recording configurations. A stream identifies the
exact set of versions currently
available for you to view, modify,
or build.
156
Cairo IT Team, ClearCase training, July 2004
UCM Terminology


Integration Stream
Development Streams
157
Cairo IT Team, ClearCase training, July 2004
Setting Up Working Areas

Adjust your UMASK
—
—

Set your umask to appropriate permission scheme.
Another build umask for derived objects is set by setting
environmental variable CCASE_BLD_UMASK
Join UCM project
Run Join Project Wizard using the command
> clearprojexp
—

Verify stream names
—
—
Development stream: By default the name given to it is
your-user-name_project-name
Integration stream: Project Manager creates the integration
stream during project creation. This stream is the default target to
which you deliver your work and from which you update your
work area.
158
Cairo IT Team, ClearCase training, July 2004
Setting Up Working Areas

Set up views
—
The wizards sets the following naming defaults :



Development view : the view name is the same as the stream name.
Integration view : the view name is
your-user-name_integration-stream-name
Access your development view
—
—
After creating your development view, the Join Project Wizard
offers to open your development view in a shell or File Browser
(xclearcase), a GUI from which you can browse files and
directories.
To access your development view using command line, you will
need to set your dynamic view and mount the VOB which contains
your project :
> cleartool setview your_view-tag
> cleartool mount vob-tag
159
Cairo IT Team, ClearCase training, July 2004
Finding and Setting Activities

Finding Activities
—
Find activities by Project Explorer GUI (using the command
clearprojexp)
—
Find activities with ClearCase Dialogs. When using xclearcase
GUI, during checkout/checkin commands you get a dialog box
from which you can find activities available to select among them
the activity you currently work at.
Find activities by command line
> cleartool lsactivity
For example:
—
> cleartool setview your_view_tag
> cd vob_tag
> cleartool lsactivity –cview
05-Aug.09:14:17 set_up_Java project pat “set up Java project”
06-Aug.14:17:19 change_copyright_notice chris “change copyright
notice”
160
Cairo IT Team, ClearCase training, July 2004
Finding and Setting Activities

Creating Activities
—
Using xclearcase GUI when performing checkin/checkout, if the
activity still not created you can use new button in Activity dialog
to create a new activity.
—
Using command line :
> cleartool mkactivity
For example:
>cleartool mkactivity –nset –headline “Your chosen headline”
Created activity with automatically generated name? [yes]
Created activity “Your chosen headline”
Where,
-nset : prevents ClearCase from setting your view to the newly
created activity.
161
Cairo IT Team, ClearCase training, July 2004
Finding and Setting Activities

Setting your view to an activity
—
Using xclearcase GUI when performing checkin/checkout, select
from Activity box the activity you want to work on.
Using command line:
> cleartool setactivity
For Example :
—
> cleartool setactivity Your_activity

Unsetting your view from an activity
—
Using command line:
>cleartool setactivity –none
162
Cairo IT Team, ClearCase training, July 2004
Working on Activities

Checking Out Elements
—
—
To modify files and directories under source control, you must
check them out. Checking out does not add versions to the
activity that is currently set in the view. (Checking in creates new
versions, which Rational ClearCase adds to the activity’s change
set.)
Use command line to checkout
>cleartool checkout –query list-of-elements
Checkout important switches :
-query : Detects potential problems in the checkout process
caused by inappropriate config specs and prompts for
action.
-nc
: Prevents ClearCase from prompting for a comment.
-cq
: Applies prompted comment to all elements in the list.
163
Cairo IT Team, ClearCase training, July 2004
Working on Activities

Working with Checkouts
—
To view an element history
> cleartool lshistory –graphical element_pathname
—
To view an element version tree
> cleartool lsvtree –graphical element_pathname
—
To compare with predecessor version
> cleartool diff –graphical –predecessor element_pathname
—
To compare with different versions
> cleartool diff –graphical element_pathname element_pathname@@version
—
To track checked out versions by myself in current view in all
vobs
> cleartool lscheckout –cview –me –avobs
164
Cairo IT Team, ClearCase training, July 2004
Working on Activities

Working with Checkouts
—
To view all activities’ change sets of current view.
> cleartool lsactivity –long –cview
—
To view current activity’s change set
> cleartool lsactivity –long –cact
activity SAMPL051111
05-Aug-01.09:14:17 by Pat (pat.user@bread)
"Created for the cropcircle_1.4 project on 09/17/00 13:25:24."
owner: pat
group: user
stream: pat_1.4_CropCircle
title: changing_copyright_strings
change set versions:
/guivob/prog.c@@/main/stream990805.090736/5
/guivob/spices.c@@/main/stream990805.090736/2
/guivob/onions.c@@/main/stream990805.090736/9
/guivob/tomatoes.c@@/main/stream990805.090736/1
/guivob/flour.c@@/main/stream990805.090736/3
165
Cairo IT Team, ClearCase training, July 2004
Working on Activities

Canceling Checkouts
—
If you check out a file but don’t want to check in your changes or
want to start with a fresh copy, you can cancel the checkout
> cleartool uncheckout element_pathname
Checkout important switches :
-keep : Saves modifications in view private file.
-rm
: Doesn’t save modifications.

Checking In Elements
> cleartool checkin -cact element_pathname
Checkout important switches :
-cact : Checkin versions checked out for the activity currently
set in your view.
-nc
: Prevents ClearCase from prompting for a comment.
-cq
: Applies prompted comment to all elements in the list.
166
Cairo IT Team, ClearCase training, July 2004
Delivering Activities

Deliver Operation
—
From your development view type
> cleartool deliver –graphical
—
—

Select the activity you want to deliver
Select the stream to deliver the
activity to (if not default target)
Deliver dependencies (Example)
—
—
You can deliver Activity B without
delivering Activity C
To deliver Activity C, which contains
version 6, you must also deliver
Activity B, which contains the
versions between 6 and the most
recent delivery of prog.c
167
Cairo IT Team, ClearCase training, July 2004
Delivering Activities

Merge Versions
—
If your project uses Rational ClearCase MultiSite to share source
data with developers in other geographical locations, and if the
project’s streams are mastered at a different site, you do not
merge versions.
—
After selecting activities, click OK in the Deliver Preview dialog
box to start merging versions in your development view with
versions in the integration view.
—
As it merges files and directories, ClearCase displays its progress
in a ClearCase UCM Deliver window. For each new version
delivered to the integration view, ClearCase merges all nonconflicting differences. To see progress of the merge, click Details
and an expansion box lists the versions in the merge
168
Cairo IT Team, ClearCase training, July 2004
Delivering Activities

Handling a Binary File in a Deliver Operation
—
If you have a binary file in any of your activities when you perform
the deliver operation, and your organization does not have a type
manager for that file type, ClearCase generates an error when it
encounters the binary file during the delivery. The error occurs
because there is no type manager that can merge the version of
the file in your development stream with the version of the file in
the integration stream
—
Your project manager can overcome this problem by creating a
special element type for the binary file type and associating that
element type with the binary file in the VOB. This special element
type can tell the ClearCase system not to attempt merging the file
169
Cairo IT Team, ClearCase training, July 2004
Delivering Activities

Undoing a Deliver Operation
—
Using the command line:
>cleartool deliver –cancel
—

Or by clicking cancel in merge manager dialog box.
Completing a Deliver Operation
—
Open the Deliver Progress dialog box from your development view, use
command line:
> cleartool deliver –complete
—
Completing a delivery of an activity means checking in merge results to the
target stream and changing the state of the operation to Complete.
170
Cairo IT Team, ClearCase training, July 2004
Delivering Activities

Deliver to non-mastered stream in MultiSite projects
—
The deliver operation determines whether your development and
target streams are mastered at different replicas. If they are
mastered at different replicas, a remote deliver operation is put
into effect. ClearCase changes mastership of the development
stream object to match that of the target stream object, and it
notifies you that it has assigned the development stream the
posted status.
—
When your development stream has the posted status, notify the
project integrator at the site that masters the target stream’s
replica. The project integrator can then find posted deliver
operations and either continue the operation or cancel it to return
the development stream to its previous state. Note that, after you
post your work, only someone at the master site can cancel or
complete the operation.
171
Cairo IT Team, ClearCase training, July 2004
Delivering Activities

Deliver to non-mastered stream in MultiSite projects
—
You can create activities and perform checkins and checkouts for
your development stream while the remote deliver is in process.
However, you cannot add, remove, or create baselines; add or
remove components; or rebase the development stream. The
delivery completes when the posted deliver operation is merged
with the target stream.
172
Cairo IT Team, ClearCase training, July 2004
Rebasing Your Work Area

Rebase Operation
—
From your development view type:
> cleartool rebase –graphical
—
—

Stop a Rebase Operation
—

Select the Baseline from the Rebase Dialog Box
Select the view you want to Rebase.
By clicking cancel in Rebase Dialog Box
Resume a Rebase Operation
—
Use the command line:
> cleartool rebase –resume –graphical
173
Cairo IT Team, ClearCase training, July 2004
Rebasing Your Work Area

Merge Versions in a Rebase Operation
—

As it does during the deliver operation, ClearCase merges all
nonconflicting differences. If versions in the baseline contain changes that
conflict with the corresponding versions in your development work area,
ClearCase prompts you to start Diff Merge so that you can resolve the
conflicts.
Cancelling a Rebase Operation
—
Using the command line:
> cleartool rebase –cancel
—

Or by clicking cancel in merge manager dialog box.
Completing a Rebase Operation
—
Open the Rebase Progress dialog box from your development view, use command
line:
> cleartool rebase –complete
—
Completing a rebase of an activity means checking in merge results to the target
stream and changing the state of the operation to Complete.
174
Cairo IT Team, ClearCase training, July 2004
GUI Sample Scenario












Invoke clearprojexp
Display project streams
Display development stream activities
Display integration stream
PVOB properties
Project properties
Project policies
Join project wizard
Set streams
Set development view
Set integration view
Join completion summary
175
Cairo IT Team, ClearCase training, July 2004
GUI Sample Scenario










Invoke xclearcase and select view
Checkout an element to modify
Attach checkout to an activity
Deliver activity from development stream
Select activity and target stream
Complete delivery process when done
Create/Modify Baseline
Baseline details
Select Baseline
Select merging view
176
Cairo IT Team, ClearCase training, July 2004
Invoke clearprojexp
177
Cairo IT Team, ClearCase training, July 2004
Display project streams
178
Cairo IT Team, ClearCase training, July 2004
Display development stream activities
179
Cairo IT Team, ClearCase training, July 2004
Display integration stream
180
Cairo IT Team, ClearCase training, July 2004
PVOB properties
181
Cairo IT Team, ClearCase training, July 2004
Project properties
182
Cairo IT Team, ClearCase training, July 2004
Project Policies
183
Cairo IT Team, ClearCase training, July 2004
Join project wizard
184
Cairo IT Team, ClearCase training, July 2004
Set streams
185
Cairo IT Team, ClearCase training, July 2004
Set development view
186
Cairo IT Team, ClearCase training, July 2004
Set integration view
187
Cairo IT Team, ClearCase training, July 2004
Join completion summary
188
Cairo IT Team, ClearCase training, July 2004
Invoke xclearcase and select view
189
Cairo IT Team, ClearCase training, July 2004
Checkout an element to modify
190
Cairo IT Team, ClearCase training, July 2004
Attach checkout to an activity
191
Cairo IT Team, ClearCase training, July 2004
Deliver activity from development stream
192
Cairo IT Team, ClearCase training, July 2004
Select activity and target stream
193
Cairo IT Team, ClearCase training, July 2004
Complete delivery process when done
194
Cairo IT Team, ClearCase training, July 2004
Create/Modify Baseline
195
Cairo IT Team, ClearCase training, July 2004
Baseline details
196
Cairo IT Team, ClearCase training, July 2004
Rebase development stream
197
Cairo IT Team, ClearCase training, July 2004
Select Baseline
198
Cairo IT Team, ClearCase training, July 2004
Select merging view
199
Cairo IT Team, ClearCase training, July 2004
Reference

This training material is based on the web training
available at the URL:
http://devnet.wv.mentorg.com/env/confman/ClearCase/training/cc_user/fbody.html
200
Cairo IT Team, ClearCase training, July 2004
Using ClearCase UCM On Windows
201
Cairo IT Team, ClearCase training, July 2004
UCM GUI Sample On Windows












Invoke clearprojexp
Display project streams
Display development stream
activities
Display integration stream
Project Actions
Project Policies
Join project wizard
Set streams
Set Views
Choose Components
Join completion summary
Snapshot View Update











202
Cairo IT Team, ClearCase training, July 2004
Checkout an element to modify
Attach checkout to an activity
Check In Element & Record In
Activity
Deliver activity from development
stream
Select activity and target stream
Complete delivery process when
done
Create/Modify Baseline
Baseline details
Rebase Development Stream
Select Baseline & Merging View
Complete the Rebase Operation
Invoke clearprojexp
StartProgramsRational SoftwareRational ClearCaseProject Explorer
203
Cairo IT Team, ClearCase training, July 2004
Display project streams
204
Cairo IT Team, ClearCase training, July 2004
Display development stream activities
205
Cairo IT Team, ClearCase training, July 2004
Display integration stream
206
Cairo IT Team, ClearCase training, July 2004
Project Actions
207
Cairo IT Team, ClearCase training, July 2004
Project Policies
208
Cairo IT Team, ClearCase training, July 2004
Join project wizard
209
Cairo IT Team, ClearCase training, July 2004
Set streams
210
Cairo IT Team, ClearCase training, July 2004
Set Types Of Views
211
Cairo IT Team, ClearCase training, July 2004
Set Development view
212
Cairo IT Team, ClearCase training, July 2004
Set integration view
213
Cairo IT Team, ClearCase training, July 2004
Choose Components
214
Cairo IT Team, ClearCase training, July 2004
Join completion summary
215
Cairo IT Team, ClearCase training, July 2004
Snapshot Views Update
216
Cairo IT Team, ClearCase training, July 2004
Checkout an element to modify
217
Cairo IT Team, ClearCase training, July 2004
Attach checkout to an activity
Then Modify Element
218
Cairo IT Team, ClearCase training, July 2004
Check In Element & Record in Activity
219
Cairo IT Team, ClearCase training, July 2004
Deliver activity from development stream
To Default Integration Stream
220
Cairo IT Team, ClearCase training, July 2004
Select activity and target stream
221
Cairo IT Team, ClearCase training, July 2004
Complete delivery process when done
222
Cairo IT Team, ClearCase training, July 2004
Create/Modify Baseline
223
Cairo IT Team, ClearCase training, July 2004
Baseline details
224
Cairo IT Team, ClearCase training, July 2004
Rebase development stream
225
Cairo IT Team, ClearCase training, July 2004
Select Baseline & Merging View
226
Cairo IT Team, ClearCase training, July 2004
Complete The Rebase Operation
227
Cairo IT Team, ClearCase training, July 2004
Reference

This training material is based on the web training
available at the URL:
http://devnet.wv.mentorg.com/env/confman/ClearCase/training/cc_user/fbody.html
228
Cairo IT Team, ClearCase training, July 2004