You are on page 1of 24

®

IBM Software Group

Essentials of Rational ClearCase


Module 6: Configuring Workspaces

1
Objectives
Upon completing this module, you should be able to:
 Explain how configuration specifications select
versions of elements
 Explain the configuration specification syntax
 Edit configuration specification rules to select
specific versions of elements
 Automate configuration specifications using
include files and the setcs command

2
Using Views: Review
 You can create multiple views to manage tasks,
typically with one view per task
 New development work
 Bug fixes
 Experimental work/research
 Each view has a config spec, a set of rules evaluated
in order, to select versions of elements
 A snapshot view config spec also contains load rules
to download selected versions
 You can use config specs to implement branching
strategies
3
Config Spec Matching
 Config spec is evaluated for
each element
 Config spec rules are
evaluated in order
 The first rule that matches,
that version appears in view
 For current rule:
 If a version matches, select
this version
 If no version matches, go to
next rule

4
Config Spec Matching: Example 1

element * CHECKEDOUT
element * /main/r2_int/LATEST
element * R1 -mkbranch r2_int

5
Config Spec Matching: Example 2
Rule 1: element * CHECKEDOUT
Rule 2: element * /main/r2_int/LATEST
Rule 3: element * R1 –mkbranch r2_int
Rule 4: element * /main/0 –mkbranch r2_int

Rule 1: If the element is checked out, select that version. If


there is no checkout, go to next rule.
Rule 2: Select the latest version on the r2_int branch. If there
is no r2_int branch, go to next rule.
Rule 3: Select the version labeled R1. Instead of checking out
the selected version, create the r2_int branch and go
through the process again starting with rule 1.
Rule 4: Rule to select new elements when adding them to
source control.
6
Config Spec Syntax
Consists of four parts:

7
Scope
element * MYLABEL -mkbranch br2

Specifies types of elements to which the rule applies.


 element
Applies to all elements
 element -dir
Applies to directory elements only
 element -file
Applies to file elements only
8
Pattern

Specifies locations in the VOB where a rule applies.


 Allows selecting from general to specific:
* => all element pathnames
src/… => entire directory tree of src
 Pathname pattern with ClearCase wildcards:
Valid characters: ? * ~ [xyz] [x-y] ...
 Restrictions
 No view extended pathnames or VOB symbolic links
 All pathnames must start at or below a VOB tag
9
Pattern: Examples
 element *.c /main/LATEST
For all files ending in .c, work on the main line
 element /hardware/src/util.c /main/LATEST
Apply this rule to only the util.c file in the src directory
 element /hardware/src/… /main/LATEST
Select /main/LATEST only from from the /hardware/src
directory, or any of its subdirectories

10
Version Selector

Specifies where a rule applies in a version tree.


 The version selected if the scope and pattern
match
 Can be dynamic: CHECKEDOUT, /main/LATEST
 Can be static: /main/4
 Can use a subset of the query language to select
versions

11
Version Selector: Examples
 /main/LATEST
Select the latest version on the main branch
 R2
Select the version labeled R2 no matter where it is
 .../bugfix/R2
Select the version labeled R2 on branch bugfix, at any
depth in the version tree
 “/main/{created_since(30-Apr)&&!
created_since(31-May)}”
Select versions created between April 30th and May 31st

12
Optional Clause

Adds an action or modifies the meaning of a rule.


 -mkbranch <branch-type>
Checkout of version selected by rule => implements auto-make-branch
routine => an instance of <branch-type> is created at that version.
Example: element * R2 -mkbranch bugfix
 -time
When used, the last version created BEFORE <date-time> is selected
on a branch instead of the version marked by LATEST.
Example: element * /main/branch/LATEST -time 5-Dec.13:00

13
Standard Configuration Rules
 The rules of the default config spec:
element * CHECKEDOUT
element * /main/LATEST
 Typically include these rules in views you use to
modify data
 You can omit these rules in views you use to see
historical data
Example:
element * R1 -nocheckout

14
Write Config Spec Rules for the
Following
1. For all elements, select the latest version on the
nt_port branch.
2. For all .c file elements, select the version labeled
R1 on the r2_int branch.
3. For all elements below any src directory, select the
latest version on the r1_bugfix branch.
4. For all elements, create a alex_dev branch off of
versions labeled R2.2 on the r2_int branch.
5. For all elements, select all versions labeled
PATCH2, but do not allow check out.
15
Write Config Specs for the Following
1. Create a new branch for your own development
off the latest version of branch r2_int.
2. Create a bugfix branch called r1_bugfix off of
element versions labeled R1.0.
3. Set up a config spec to build the product, taking
all JPEG files (.jpg) from the main line, but all
others from the r2_int branch.
4. Work on the main line of the directory, but set up
a shared bugfix branch off main for files.

16
Managing Config Specs with Include
Files
 Ensures that team members are using the same
config spec
 Allows users to share the same set of rules, while
still maintaining the “privacy” of their own view
 These config specs can reside on a server and be
maintained by the project lead
Example:
include \\server\views\config_spec\rel3

17
Managing Config Specs with setcs
 Makes a specified file (user-specified or system-
default) a view’s config spec
 Can be used to set a user’s config spec to a
configuration designed and maintained by the
project lead
 If the project lead changes the configuration, the
user performs another setcs
Example:
cleartool setcs
\\server\views\config_spec\rel3

18
Displaying and Editing Config Specs:
Review

To view a config spec, click


Properties of View.

To edit the config spec,


click Edit.

19
Error Checking
ClearCase checks for config spec syntax errors.

20
Viewing Rule Selection

21
Module Review
 How does a config spec select versions?
 What are the parts of the config spec syntax? What does
each do?
 Which parts of the config spec syntax are required? What
happens if one is omitted?
 What are the default config spec rules? When might you
choose not to use them?
 What does an include rule in a config spec do?
 What does the setcs command do?
 How do you change a view config spec?

22
Module Lab
 In this lab, you will perform the following tasks:
 Use the ClearCase GUI to create a view
 Edit the config spec to automatically create
branches
 Edit the config spec from the command line

23
24

You might also like