Download - ClearCase Training January 2005 Cairo Clearcase Team Cairo, Egypt Amr Elhusseiny IT Manager

ClearCase TrainingJanuary 2005

Cairo Clearcase TeamCairo, Egypt

Amr ElhusseinyIT Manager

Cairo IT Team, ClearCase training, July 20042

Clearcase support at Mentor Graphics

Europe/middle east North America

Amr ElhusseinyAmr Elhusseiny

Asser SherifAsser Sherif

Ahmed FayekAhmed Fayek

Richard EnglandRichard England

Roger MooreRoger Moore

Cairo-EgyptCairo-Egypt WV-USAWV-USA


General Concepts Using ClearCase On UNIX Using ClearCase On Windows How To work From Home (snapshot) Build Control UCM On Unix UCM On Windows

ClearCase Training


Configuration Management (Concepts and Goals)

Data Storage – VOBs

Meta-Data for Process Control

General Concepts


“General Concepts” Configuration Management Concepts Tracking objects and changes to the objects Tracking the relationships and changes to the

relationships between objects, Ex: o Unit tests and source o Source and requirements o 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


Improve the Return on Investment by:

Increasing team productivity

Increasing product quality

Managing process quality

Reducing the time to market

Reusing code when applicable

“General Concepts” Configuration Management Goals


“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.


“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.



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)



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.



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



Accessing VOB Data Using a View, Cont.



Metadata For Process Control

Labels

Attributes

Branching

Hyperlinks

Element Types

Triggers

Locks



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



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.



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


“Using VOBs and Views” Branches and Parallel Development

/main

0

1

2 C4

myfile.c

0

/bugs

2

0

1

0

1

/enhancements

/bug104

1

Label

Branch

Merge


“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.


“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



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



Hyperlinks, Cont.

2 1 1

23

/main

0

1 0/bugfix

/main

0

1 0/bugfix

myfile.c myfile.doc

QA_LINKQA_LINK -> /vob/project/myfile.doc

@@/main/bugfix/2

QA_LINK <- /vob/project/myfile.c @@/main/bugfix/1A hyperlink is an annotation that depicts a

relationship between two objects


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



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.



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


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


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



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.



Using VOBs and Views

View types and their differences

Using Config specs


“Using VOBs and Views” View Types and Their Differences

Config Specs Rules

VOB

Versioned Object Base

DYNAMIC VIEW

SNAPSHOT VIEW

Config Specs Rules

VIEW Files VIEW Files


“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.



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.



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.


MultiVersion File SystemMVFS

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)


“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.


“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



Config specs, examples:

element * CHECKEDOUT

element * .../mybranch/latest

element *.c RELEASE_2.0

element * /main/latest -mkbranch

mybranch



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.



Build and test engineers should use something like:

element * LABELNAME

Working on snapshot view:

load /vobs/<VOB_TAG>


element * /main/LATEST

Developers should use something like:


element * .../mybranch/LATEST

element * LABELNAME -mkbranch mybranch


Checkout / Checkin Model

Checkout

myfile.c

VOB

Versioned Object Base

DYNAMIC VIEW

Config Specs Rules

VIEW Files

Checkin

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


Checkout / Checkin Model, Cont.

3

R U

3

R U

4

3

R

3

4

RESERVED Checkout UNRESERVED Checkout

Checkout

Checkin

Checkout Checkout

Checkin

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.


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.


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.


Using ClearCase On UNIX


Base Clearcase under Unix


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 )


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 richard staff 2048 Jan 2 1997 private drwxrws--- 2 richard staff 2048 Jan 2 1997 admin -rw-rw---- 2 richard staff 12040 Aug 20 1996 userinfo drwxr-xr-x 3 richard user 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 filesdrwxr-xr-x for directories


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 filesdrwxrwxr-x for directories


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.


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


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


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


Working with Dynamic Views

Set a dynamic view to be your current VIEW

>cleartool setview your_view_tag

Print your current dynamic VIEW

>cleartool pwvWorking directory view: ** NONE **Set view: your_view_tag

NEVER remove the view using UNIX command rm –rf


Config Spec – Dynamic View

View your configuration specs>cleartool catcs

element * CHECKEDOUTelement * /main/LATEST

Edit your configuration Specs>cleartool edcs

element * CHECKEDOUTelement * /main/LATEST

Set config spec for view “view-tag” ? [Yes]

Set configuration Specs file >cleartool setcs file_name


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


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


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 theVOB 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.


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 /guivobinto 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


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.


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


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


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


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


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


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


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


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


Working in a Snapshot View Without the Network (Laptop)

While on network:— Update the view from the VOB— Check out the files you intend to work on offline— Deactivate clearcase integrations

Disconnect from Network:— 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


Working with Vobs

List files in a VOB>lsfile_name archive db test_data test_log version

>cleartool lsfile_name@@/main/1 Rule: /main/LATESTarchive@@/main/1 Rule: /main/LATESTdb@@/main/1 Rule: /main/LATESTtest_data@@/main/1 Rule: /main/LATESTtest_log@@/main/1 Rule: /main/LATESTversion@@/main/4 Rule: /main/LATEST

>cleartool ls -longversion file_name@@/main/1 Rule: element * /main/LATESTdirectory version archive@@/main/1 Rule: element * /main/LATESTdirectory version db@@/main/1 Rule: element * /main/LATESTdirectory version test_data@@/main/1 Rule: element * /main/LATESTdirectory version test_log@@/main/1 Rule: element * /main/LATESTversion version@@/main/4 Rule: element * /main/LATEST


Working with Vobs..Cont

List version of a file in a VOB

>cleartool lsvtree file_namefile_name@@/main

file_name@@/main/4

>cleartool lsvtree –all file_namefile_name@@/main

file_name@@/main/0

file_name@@/main/1

file_name@@/main/2

file_name@@/main/3

file_name@@/main/4


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


Checkout / Checkin Files

Checkout a file>cleartool checkout myfile.cCheckout comments for “myfile.c”Fix Bug 102..Checked out “myfile.c” from version “/main/3”.

List Checked out files>cleartool lscheckout –me (By current login)

>cleartool lscheckout –cview (In current VIEW)

>cleartool lscheckout –all (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”.


Creating new elements Add new directory to a VOB

> cleartool mkdir docCreation 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.txtCreation comments for “document1.txt”:

New document.Created element “document1.txt” (type “text_file”)Checked out “document1.txt” from version “/main/0”.


Metadata for Process Control

Labels

Attributes

Branching

Merging

Hyperlinks

Element Types

Triggers


Labels

Declare new label type>cleartool mklbtype –c “Release2” REL2Created label type “REL2” .

List Label types declared>cleartool lstype -kind lbtype05-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.cCreated label “REL2” on “myfile.c” version “/main/4”


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 versionor even hyperlinks and symbolic links and their usage can berestricted to specific branch, version by –vpbranch , -vpversionswitches


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 –config hello.exe –replace qa_tested /”waiting/”

Created attribute “qa_tested” on “/project/@@/main/3”

Created attribute “qa_tested” on “/project/src/@@/main/2”

Created attribute “qa_tested” on “/project/src/myfile.c@@/main/2”

Created attribute “qa_tested” on “/project/src/myfile.h@@/main/2”

Remove attribute instance>cleartool rmattr Stage myfile.c


Branching

Declare new branch type>cleartool mkbrtype –c “Bug Fixes” rel2_bugsCreated branch type “rel2_bugs” .

List branch types>cleartool lstype -kind brtype05-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"


Branching

Branch a file>cleartool mkbranch rel2_bugs myfile.cCreation 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


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 * …/rel2_bugfix/LATEST

element * /main/LATEST –mkbranch rel2_bugfix


Merging

Merge Algebra base contrib 1 contrib 2 merge

result

F

A A A A

B

D

E

C

D

Q

B

Z

?

deleted

inserted

changed

deleted

C inserted

changed Z changed

changed conflict


Merging

2

0

/main

0

1

1

/bugsBranch

3

Merge

A common merge practice

Merge from bugs branch to the main branch of the file


Merging

>cleartool co myfile.c@@/main/LATESTCheckout 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 catcselement * CHECKEDOUT

element * /main/bugs/LATEST

element * /main/LATEST


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] yApplying INSERT from file 2 [lines 12-13]Do you want the INSERTION made in file 3? [no] yApplying 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".


Merging>cleartool describe myfile.cversion "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


Merging

>cleartool checkin -nc myfile.c

cleartool: Warning: Version checked in is not selected by view.

Checked in "myfile.c" version "/main/4".


Hyperlinks

2 1 1

23

/main

0

1 0/bugfix

/main

0

1 0/bugfix

myfile.c myfile.doc

QA_LINKQA_LINK -> /vob/project/myfile.doc

@@/main/bugfix/2

QA_LINK <- /vob/project/myfile.c @@/main/bugfix/1A hyperlink is an annotation that depicts a

relationship between two objects


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”.


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


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.vhdCreated 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.abcCreated element “and2.abc” (type “text_file”).Checked out “and2.abc” from version “/main/0”


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.


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]" ;


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


Build Control

Build tools Additional features in clearmake Derived Objects Configuration Records Manipulating Derived Objects Parallel and Distributed Builds


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


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


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


Derived Objects

List derived objects :>cleartool lsdo –long23-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


Configuration Records

View configuration records (CR) :>cleartool catcr reg_model.exe

Target exec built by username.sysadminHost “plkview" running SunOS 5.8 (sun4u)Reference Time 23-Aug-02.12:11:12, this audit started 23-Aug-

02.12:13:38View was plkview:/net/plkview/views/username_regmodel_vu.vwsInitial working directory was /vobs/plk_IT_basetrain/regmodel/ss6----------------------------MVFS objects:----------------------------/vobs/plk_IT_basetrain/regmodel/src/glue/Makefile@@/main/1 <06-Jun-

02.10:08:48>/vobs/plk_IT_basetrain/regmodel/src/glue/overrides.mk@@/main/1 <02-Jul-

99.01:35:08>/vobs/plk_IT_basetrain/regmodel/src/glue/overrides.ss6.mk@@/main/1 <02-

Aug-00.00:25:23>…



----------------------------

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

----------------------------



Comparing config records>cleartool diffcr regmodel.exe regmodel.exe@@31-Oct.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


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


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


Using ClearCase On Windows


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


How To share The View LocationThe 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.


ClearCase Program menu


ClearCase Home Base User Interface


ClearCase Properties


Make Sure CC Is Running


Stopping CC

If ClearCase If ClearCase Cannot be Cannot be stopped/restarted, stopped/restarted, you have to you have to restart your PC.restart your PC.


ClearCase Properties


Create View


Create View, Cont.


Create Dynamic View


Create Dynamic View, Cont.

The Mapped Drive The Mapped Drive Letter could be any Letter could be any free mapping Letter. free mapping Letter. Ex: Z, Y, X, …. Ex: Z, Y, X, …. Check Network Check Network Drives in “My Drives in “My Computer” Or Computer” Or “Windows Explorer”“Windows Explorer”

loginname_loginname_vuvu


Create Dynamic View, Cont.Advanced Options

\\machine\\\machine\cc_viewscc_views\\MGCMGC\loginname\loginname_vu.vws\loginname\loginname_vu.vws

plk_ntplk_nt


Create Snapshot View


Create Snapshot View, Cont.

E:\E:\cc_viewscc_views\\MGCMGC\loginname\loginname_snap_vu\loginname\loginname_snap_vu


Create Snapshot View, Cont.Advanced Options

E:\E:\cc_viewscc_views\\MGCMGC\loginname\loginname_snap_vu.vws\loginname\loginname_snap_vu.vws

loginname_snap_vuloginname_snap_vu



E:\E:\cc_viewscc_views\\MGCMGC\loginname\loginname_snap_vu\loginname\loginname_snap_vu


Create Snapshot View, Cont.Select VOBs/Elements To Load



loginname_snap_vuloginname_snap_vu


Updating Snapshot View


Remove View


Remove View, Cont.


Remove View, Cont.

test_tmp_vutest_tmp_vu


ClearCase Doctor


Context Sensitive Menus


Mounting VOBs


Compare Versions

Comparing with Comparing with Previous Version is Previous Version is not always successful. not always successful. It depends on the file It depends on the file type. Ex: It Can’t be type. Ex: It Can’t be done with MS done with MS Project .mpp files and Project .mpp files and certain MS Word certain MS Word versions.versions.


Element Properties


Version Tree Browser


Version Tree Browser, Cont.


UCM On UNIX

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


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.


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.


UCM Workflow


UCM Workflow

- Join UCM Project.

- Create 2 work areas :

- Private area for working in isolation in activities

- Shared area for testing activities delivered


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.


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.


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.


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.


Roles and Responsibilities

Project manager — Allocates components and activities for the project — Determines initial milestones (baselines) — Specifies the project's policies and tasks

Architect — Translates project architecture into directory structure

Administrator — Creates and maintains the infrastructure


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


UCM Terminology

Elements— Files and directories put under version control of Clearcase.

Components— 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 base-line, which records one version of each element in a component. In effect, a base-line is a version of a component.


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 config-urations. A stream identifies the exact set of versions currentlyavailable for you to view, modify, or build.


UCM Terminology

Integration Stream

Development Streams


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.


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


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 –cview05-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”



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 mkactivityFor 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.



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


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.



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



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 –cactactivity SAMPL05111105-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: patgroup: userstream: pat_1.4_CropCircletitle: changing_copyright_stringschange 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



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.


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



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 non-conflicting differences. To see progress of the merge, click Details and an expansion box lists the versions in the merge



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



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.



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.



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.


Rebasing Your Work Area

Rebase Operation— From your development view type:

> cleartool rebase –graphical

— Select the Baseline from the Rebase Dialog Box— Select the view you want to Rebase.

Stop a Rebase Operation— By clicking cancel in Rebase Dialog Box

Resume a Rebase Operation— Use the command line:

> cleartool rebase –resume –graphical


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.


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


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


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


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


Rebase development stream


Select Baseline


Select merging view


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.htmlhttp://devnet.wv.mentorg.com/env/confman/ClearCase/training/cc_user/fbody.html


Using ClearCase UCM On Windows


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

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 clearprojexpStartProgramsRational SoftwareRational ClearCaseProject Explorer


Display project streams


Display development stream activities


Display integration stream


Project Actions


Project Policies


Join project wizard


Set streams


Set Types Of Views


Set Development view


Set integration view


Choose Components


Join completion summary


Snapshot Views Update


Checkout an element to modify


Attach checkout to an activityThen Modify Element


Check In Element & Record in Activity


Deliver activity from development streamTo Default Integration Stream