configuration management with clearcase

Copyright, 2006Dipl. Inform. Uwe Satthoff

1. Basic concepts for usage2. Basic concepts for administration3. Setup of example environment

27.09.2006 - 28.09.200612.10.2006 - 13.10.2006

Configuration Managementwith ClearCase


Configuration Managementwith ClearCase

Basic concepts for usage


WHYWHYClearCase

??


WHYWHYConfiguration Management

??


The real world


The real world

Project A

Project B

Project C

Project D


The real world

Project A

Project B

Project C

Project DDeployment


The real world

Project A

Project B

Project C

Project DDeployment

Costumer


The real world

Project A

Project B

Project C

Project DDeployment

Costumer

problem tracking


The real world

Project A

Project B

Project C

Project DDeployment

Costumer

problem tracking

change trackingparallel development/maintenance


The real world

Project A

Project B

Project C

Project DDeployment

Costumer

problem tracking

change trackingparallel development/maintenance

configuration

management


Outcome: What do we need for Configuration Management ?

object management version control system

history management

rich branching, labeling, merging

workspace management independent work areas for different roles like

developer, integrator, tester, release manager, ....

transparent access to different system configurations

build management

process management


Basic rules for Configuration Management

unique identification of all artifacts (readable by humans) software product versions (configurations)

parallel workstreams

software builds

single source principle each object exists once, keeping all evaluation history in itself

redundancy has to be avoided at all

insulated but not isolated working environments


cc.c

1

2

3

cc.h

1

2

3

4

Xy.so

1

2

cc

1

2

3

Unique named configurations


cc.c

1

2

3

cc.h

1

2

3

4

Xy.so

1

2

cc

1

2

3

Unique named configurations

Product-V1

Product-V2


WHATWHAToffersoffers

ClearCase??


ClearCase environment


What is a VOB?

Versioned Object DataBase container for all sort of data in

different versions (elements withversions)

identified through unique name (VOB-tag)

metadata used to organizechanges

tracks all changes in history

Elements Metadata History

cc.c

produktion

testet

CREATE

user

14.07.2006


What is a view?

a user work area is the interface to VOBs

VOB contents can only be accessed via views

maps dynamically exactly one version of each element to the user‘s work area,

like a filter, defined by the configuration specification (config spec)

users can have as many views as they like

cc.c cc.h

src

Configuration specification

cc.c

cc.h

src


VOBs, views, Multi Version File System


VOBs appear in views as ordinary directory trees


virtual work area: view private data in VOB directory


checkout, edit, checkin model


Exercises:

create a VOB cleartool mkvob -tag /vobs/name -public /<storage>/vobstore/name.vbs

mount the VOB cleartool mount /vobs/name

create a view cleartool mkview -tag name /<storage>/viewstore/name.vws

start the view cleartool setview name what is your current view ? -> cleartool pwv

list existing VOBs and views, show properties of VOBs and views cleartool lsvob [-long] [VOB-tag] cleartool lsview [-long] [view-tag] cleartool describe [-long] vob:VOB-tag


What is an element ?

a version controlled directory orfile of any type (e.g. source,binary, object library, document) file type is automatically determined

by ClearCase at element creation time

identified by pathname in the VOB

a container for all versions of the directory or file

Elements

cc.c

xy.c

lib.o


ClearCase element permissions

permission system is based on operating system permissions owner, group, other e.g. drwxrwxr-x admvob vobgroup /vobs/myVob/a_vob_directory

ClearCase VOB group(s) each VOB is owned by one account and one group each VOB may have a list of additional groups

user process settings & membership of groups determines access primary group of accessing process must be in VOB’s group list to be

permitted to create new elements existing element can be checked out, if owned by user or user belongs to

the elements group or element has write access for others


What is a version ?

a version identifies the contents of a file or directory at a certain point of time

each modification of an element is mapped to a new version

a delta storage in the data container of the element

Elements

cc.c

xy.c

lib.o


Exercises:

Change working directory, step into the VOB cd /vobs/name

root element permissions ls -lad . What is your current view ? : cleartool pwv

which version of the root directory do you see cleartool ls -l -d .

which versions of the root directory exist cleartool lsvtree .


An element’s version tree (default cspec)

branch

version

label

label


An element’s version tree (UNIX style)

branch

branch

merge arrow

label

many labels on one version


What is meta data?

data objects to organize elements and versions

most commonly used:label type, branch type, attribute type

others:element type, hyperlink type, trigger type

Metadata

cc.c

produktion

testet

cc.h

depends


What is a config spec? a sequence of version selection

rules interpreted from top to bottom by

the view‘s view server process for each element accessed by the

user process interpretation stops at the first

rule, which selects a version, and this version is mapped to the

user‘s workspace the rules are based on meta data like

labels, branches and even on time stamps

users can change the cspeccc.c cc.

hsrc

Config spec :...element * TESTED...element * /main/LATEST

cc.c

cc.h

src


The default config spec

element * CHECKEDOUTelement * /main/LATEST

new ClearCase views gets first the default config spec assigned

The rule key word

The rule path

The version selection:the LATEST version on

branch main

The version selection:the CHECKEDOUT version in the

current view


Exercises:

have a look to your view’s config spec cleartool catcs

have a look to another view’s config spec cleartool catcs -tag another_view

have a look to the VOB contents selected by your view cd VOB-tag, e.g. cd /vobs/myvob

modify the VOB contents, create new elements view private : echo “hallo moin” > moin.txt; vi newFile; cp /file myFile checkout directory : cleartool co -c ‘comment’ . create element : cleartool mkelem -nc moin.txt checkin version : cleartool ci -nc moin.txt checkin directory : cleartool ci -nc . create VOB directoy : cleartool co -nc .; cleartool mkdir newDir


Exercises:

How to import many objects, i.e. a complete subtree, into a ClearCase VOB ?

Use the import utility clearfsimport: clearfsimport [-r] [-mklabel <label>] <source> <target> e.g.:

clearfsimport -r /home/me /vobs/myvob/subdirimports the complete subtree /home/me into the VOB myvob at location/vobs/myvob/subdir/me

different usage for VOB owner and other users: option -nseteventif the VOB owner uses the command, it is breakable and re-startable at any point in time


again : meta data

branch type => branches

label type => labels

attribute type => attributes

hyperlink type => hyperlinks

trigger type => triggers

element type => elements


Exercises:

create a new label type cleartool mklbtype -c ‘comment’ label_type_name

attach label to version of an element cleartool mklabel label_type_name element_name

attach labels to versions of elements in a subtree cleartool mklabel -r label_type_name pathname

attach label to a specific version of an element cleartool mklabel label_type_name moin.txt@@/main/4 moin.txt@@/main/4 == version extended pathname

move an existing label to another version of the same element cleartool mklabel -replace label_type_name element_name

have a look to the version tree of an element cleartool lsvtree [-graphical] element_name


example config spec

element * CHECKEDOUTelement * RELEASE_V1element *.doc DOC_V1element * /main/LATEST

Select versionlabeled

RELEASE_V1

Select versionof files *.doc labeled

DOC_V1

Config specs are interpreted from TOP to BOTTOM,finding the first matching rule

Discussion:file element A.doc has one version labeled RELEASE_V1.Which rule matches ?


example config spec

element * CHECKEDOUTelement -directory * /main/LATESTelement * .../my_branch/LATESTelement * /main/LATEST

Select LATEST version on branch

/main for directories

If element has branch my_branch, select LATEST version on

this branchOtherwise select

LATEST version on branch /main


Exercises:

create a new branch type cleartool mkbrtype -c ‘comment’ branch_type_name

list existing types cleartool lstype [-long] -kind lbtype|brtype|attype|hltype|eltype|trtype

modify your config spec cleartool edcs [-tag viewname] vi cspec.file; cleartool setcs cspec.file

see the effects of config spec change cleartool ls -long # again modify config spec cleartool ls -long

let’s “play” with views, labels, cleartool commands


A “auto branch” config spec

element * CHECKEDOUTelement * .../bugfix_4711/LATESTmkbranch bugfix_4711element * INTEG_PRODUCT_0element * /main/0end mkbranch bugfix_4711

mkbranch keyword:branch block definesbaseline of branch

Select versionlabeled

INTEG_PRODUCT_0

the LATEST version on branch

bugfix_4711

mkbranch keyword:branch block definesbaseline of branch

For new elements,which do not have the baseline label


An element’s version tree (auto branch cspec)

(auto) branch


Exercise: a more real problem

Task description Our customer reported a bug in the last delivered version = P-31 of our

product. This bug is tracked in our problem tracking system as problem number

4711. We know, that the software configuration which existed at creation time of

product version P-31 is identified by the label type INTEG_PRODUCT_0 in our ClearCase VOB /vobs/project-p.

We have to fix the problem without hindering the further development of our product.

The implementation of the fix has to be identified as P-31.P-4711. After patch delivery we have to check, whether the implementation can be

integrated in the latest version of our product, which has been further developed in the meantime.


Exercise: a more real problem

Setup of the environment - what do we need ? Independent work space

ct mkview -tag ......... Enable work in parallel to ongoing development

ct mkbrtype -nc ....... Ensure that all changes are performed on seperate branch

ct edcs (use the automatic branching in config specs) After implementation identify patch as requested

ct mklbtype -nc .....; ct mklabel -r ..... After patch delivery, integrate with ongoing development

?? Again new work space, or use patch work space ?? ?? How to integrate : new commands for merging

ct merge .... ct findmerge ....


Most important commands:

Create new elements cleartool mkelem ...; cleartool mkdir ...

Change existing elements cleartool co; cleartool ci

Merge contents from other versions cleartool merge -to <element> -version <version selector> cleartool findmerge <path> -fve <version selector> -merge | -print

List existing checkouts cleartool lsco [-r] [-cview] [-short] [<path>]

List view privates cleartool lspriv

View man pages cleartool man <command>; cleartool apropose <item>


QUESTIONSQUESTIONS&&

ANSWERSANSWERS

configuration management with clearcase

Documents