Configuration Management with ClearCase

1. Configuration Managementwith ClearCase 1. Basic concepts for usage 2. Basic concepts for administration 3. Setup of example environment 27.09.2006 - 28.09.2006 12.10.2006 - 13.10.2006

2. Configuration Managementwith ClearCaseBasic concepts for usage

3. WHYClearCase?

4. WHYConfiguration Management?

5. The real world

6. The real world Project D Project C Project B Project A

7. The real world D e p l o y m e n t Project D Project C Project B Project A

8. The real world D e p l o y m e n t C o s t u m e r Project D Project C Project B Project A

9. The real world D e p l o y m e n t C o s t u m e r Project D Project C Project B Project A problem tracking

10. The real world D e p l o y m e n t C o s t u m e r Project D Project C Project B Project A problem tracking change tracking parallel development/maintenance

11. The real world D e p l o y m e n t C o s t u m e r Project D Project C Project B Project A problem tracking change tracking configuration management parallel development/maintenance

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

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

14. Unique named configurations cc.c cc.h Xy.so cc 1 1 1 1 2 2 2 2 3 3 3 4

15. Unique named configurations cc.c cc.h Xy.so cc Product-V1 1 1 1 1 2 2 2 2 Product-V2 3 3 3 4

16. Unique named configurations cc.c cc.h Xy.so cc Product-V1 1 1 1 1 2 2 2 2 Product-V2 3 3 3 4

17. WHAToffersClearCase?

18. ClearCase environment

19. 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 VOB Elements Metadata History cc.c CREATE user 14.07.2006 testet produktion

20. 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 VIEW cc.c src cc.h Configuration specification VOB cc.c src cc.h

21. VOBs, views, Multi Version File System

22. VOBs appear in views as ordinary directory trees

23. virtual work area: view private data in VOB directory

24. checkout, edit, checkin model

25. 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 Exercises:

26. 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 VOB Elements xy.c cc.c lib.o

27. 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 ClearCase element permissions

28. 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 VOB Elements xy.c cc.c lib.o

29. 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 . Exercises:

30. An element’s version tree (default cspec) branch version label label

31. An element’s version tree (UNIX style) branch merge arrow branch label many labels on one version

32. 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 VOB Metadata depends cc.h cc.c testet produktion

33. 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 cspec VIEW cc.c src cc.h Config spec : ... element * TESTED ... element * /main/LATEST VOB cc.c src cc.h

34. element * CHECKEDOUT element * /main/LATEST The default config spec • new ClearCase views gets first the default config spec assigned The version selection: the CHECKEDOUT version in the current view The version selection: the LATEST version on branch main The rule key word The rule path

35. 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:

36. 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 Exercises:

37. again : meta data branch type => branches label type => labels attribute type => attributes hyperlink type => hyperlinks trigger type => triggers element type => elements

38. 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 Exercises:

39. element * CHECKEDOUT element * RELEASE_V1 element *.doc DOC_V1 element * /main/LATEST example config spec • Config specs are interpreted from TOP to BOTTOM,finding the first matching rule Select version labeled RELEASE_V1 Select version of files *.doc labeled DOC_V1 Discussion:file element A.doc has one version labeled RELEASE_V1.Which rule matches ?

40. element * CHECKEDOUT element -directory * /main/LATEST element * .../my_branch/LATEST element * /main/LATEST example config spec Select LATEST version on branch /main for directories If element has branch my_branch, select LATEST version on this branch Otherwise select LATEST version on branch /main

41. 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 Exercises:

42. element * CHECKEDOUT element * .../bugfix_4711/LATEST mkbranch bugfix_4711 element * INTEG_PRODUCT_0 element * /main/0 end mkbranch bugfix_4711 A “auto branch” config spec For new elements,which do not have the baseline label the LATEST version on branch bugfix_4711 Select version labeled INTEG_PRODUCT_0 mkbranch keyword: branch block defines baseline of branch mkbranch keyword: branch block defines baseline of branch

43. An element’s version tree (auto branch cspec) (auto) branch

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

45. 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 .... Exercise: a more real problem

46. 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> Most important commands:

47. QUESTIONS&ANSWERS