INTERNAL
___________________________________________________________________________________________________
Ray Lee
Abstract: This document provides user level information for working with the CQCM Clear-
Quest/ClearCase integration.
Document No: COM-TOOL-CM-UG-003
Version: 1.06
20-Feb-2009 Date:
Status: RELEASED
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 1
Doc Version: Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Revision History
Version Date
1.00
Author
30 May 2007 Ray Lee
1.01
1.02
1.03
1.04
1.05
1.06
28 Nov. 2007 Tracy Lou
6 Aug. 2008
12 Aug 2008
Tracy Lou
Ray Lee
16 Oct 2008 Tracy Lou
29 Jan 2009 Ray Lee
20 Feb 2009 Tracy Lou
Contributors Change Tracker Description
Larry Eyberger SR INDEV00120279 Migrated document to
CR INDEV00121054 CQCM. Old ID was WSG-
Ray Lee
Ray Lee
Tracy Lou
Ray Lee
Randy Erbacci
Ray Lee
TOOL-CM-UG-001
CR INDEV00131234 Added new loadline market number; Updated for new scBRMerge -ba.seline syntax
CR INDEV00144729 Added new loadline market number
CR INDEV00144749 Updated document to allow current restriction of Dev-
Int CR to Dev-Int CR merges and creation of
Dev-Int CR brtypes/views with Target_Type=Dev-
Build.
CR INDEV00147475 Updated document for the new prompting when authenticating CQ username;
Updated document for the updated procedure to display "My Assigned CRs" list from cleartool mkbrtype command;
CR INDEV00150669 Updated document for new mkview option to also display “My Assigned
CRs”
CR INDEV00153098 Updated document for mkt72 loadline mapping change;
Updated document for
Merge Stata entry correction for scMergeList action in Merge State table
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003
Doc Version: Version: 1.06
2

INTERNAL
___________________________________________________________________________________________________
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preface 5
Purpose and Scope ................................................................................................5
References ......................................................................................................................... 5
Where to go for help ........................................................................................................ 6
Intended audience ............................................................................................................ 6
Operating Environment ................................................................................................... 6
Typographical Conventions ............................................................................................. 7
ClearCase Comment Conventions .................................................................................. 7
About this document ........................................................................................................ 8
Glossary of Key Terms ..................................................................................................... 8
. . . . . . . . . . . .CC/CQ Integration Introduction 12
CM Process ..........................................................................................................13
Integrated Flow ........................................................................................................................ 13
Getting Started ............................................................................................................... 13
A Typical software development lifecycle flow .......................................................... 14
View Creation ................................................................................................................. 16
Devprojects .............................................................................................................................. 17
Windows ClearCase ....................................................................................................... 19
Navigating the VOBS .........................................................................................20
Contacting local CC admin(s) (ccContact) .......................................................20
. . . . . . . . . . . . . Rebase Operations and Testing 22
View Rebase Concepts ........................................................................................22
View Rebase Process ...................................................................................................... 22
View Rebase Procedures ................................................................................................ 23
Build and Unit Testing ................................................................................................... 25
Lock Branch ................................................................................................................... 26
Submit Work ................................................................................................................... 26
CR Technical Authority Re-assignment in ClearCase ....................................27
ClearCase Permission Levels ........................................................................................ 27
Re-assignment of CR Branch Type ......................................................................................... 28
TA Re-assignment Scenarios ......................................................................................... 29
. . . . . . . . . . . . . . . . . . . . . . . . . .CR Dependency 30
. . . . . . . . . . . . . Integration Phase of CR Work 33
Overview of Integration Process Flow .............................................................33
Coordinator Edits the CR ............................................................................................. 35
Push and Pull Merging Techniques .............................................................................. 35
Merge Management Tools ............................................................................................. 37
Merge States in CQCM CQ/CC Integration ............................................................... 40
Development Integration with Dev-Int CRs & Branches ........................................... 43
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 3
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Creating and Assigning a Dev-Int CR ..................................................................................... 44
Creating a Dev-Int CR branch & view .................................................................................... 45
Configuring a Dev-Int CR branch ........................................................................................... 45
Creating and Using Dev-Build Baselines for a Dev-Int CR .................................................... 46
Targeting Changes to a Dev-Int branch ................................................................................... 47
Merging Changes to a Dev-Int branch ..................................................................................... 48
Rebase the Dev-Int Branch from the Target Integration Branch ............................................. 52
Finishing and Merging a Dev-Int CR Branch .......................................................................... 53
Propagation (Porting) Tools .......................................................................................... 54
Restricting Access to a VOB Element .......................................................................... 55
. Integration Examples Using the Sandbox 56
Example 1 - Basic Flow with CQ/CC Integration ....................................................... 56
Example 2 - Development/Integration Flow with Agile Process ................................ 58
Example 3 Merging using a Baseline Record .............................................................. 63
Additional Examples of Mkview ................................................................................... 65
Example 1 : Alternate mainline view using DevProject files for including customized rules 65
Example 2 : Alternate mainline view without DevProject files ............................................. 66
Example 3 : CR view using bldlabels functionality to automatically determine baseline ..... 66
Example 4 : CR view using bldlabels and component functionality ..................................... 67
Example 5 : Sandbox (Tmp) View ......................................................................................... 67
Example 6: Dev-Int View (ClearQuest CR_Usage=Dev-Integration) ................................... 67
Example 7: Dev-Int View (ClearQuest CR_Usage=Dev-Integration) ................................... 68
Example 8: Dev-CR View Targeted to Dev-Int (ClearQuest CR Target_Type=Dev-Build) .. 68
Example 9: mkview with option to display list of currently “My Assigned CRs” ................. 68
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 4
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
This user guide provides a basic understanding of the CQCM development environment in terms of Clear-
Case and ClearQuest integration. The content deals with the Change Record (CR) portion of the ClearQuest domain, which means that it deals only with the process once a CR has been assigned to a developer who then performs work on the CR. After reading this document, the reader should be able to utilize ClearCase integration to work on CRs.
Configuration Management (CM) consists of Change Management (ChM) and Version Control (VC) processes and procedures for source code and documentation. Configuration Items (CIs) are identified and placed under the CM system. This synthesis of process and related procedures is integrated and reinforced by the toolset from Rational Clearquest (CQ) and ClearCase (CC). The ChM portion of CM for this implementation is termed CQCM (ClearQuest Change Management).
This document should be used in conjunction with CQCM ClearQuest user documentation and ClearCase
Concepts and Reference Guide (see References section).
The scope and purpose of this document is as follows.
• Covers the role of the Technical Authority (TA) once assigned a ClearQuest CR.
• Covers the process of making changes on branches.
• Covers keeping the development branch current with a new release (Rebaseline).
• Covers merging changes by pushing them to a development-integration or pre-integration branch.
• Covers the handoff process to an integrator for build and test and eventual release.
• Covers the Push/Pull integration models.
[1] ClearCase MetaData Standards and Definitions , WSG-PROC-CM-STD-004
[2] ClearCase VOB and MultiSite Planning , WSG-PROC-CM-REF-003
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 5
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
[3] WSG CMBP Software Build Process , WSG-PROC-CM-PROC-001
[4] CQCM ClearQuest User’s Guide, COM-TOOL-CM-UG-001
[5] Rational ClearCase Manuals , Version 4.0 (http://scm.gtss.mot.com/rationalman.html)
[6] ClearCase Concepts and Reference Guide , COM-TOOL-CM-REF-001
[7] CQCM ClearCase Administration Guide , COM-TOOL-CM-UG-004
[8] WSG CMBlueprint Multiple Loadline Management Process , WSG-PROC-CM-PROC-014
• For general information, Training, Userguides and updates on CQCM go to the following webpage: http://compass.mot.com/web/cqcm.
• For installation information for CQCM ClearQuest and ClearCase on Windows or UNIX, see your local
CQ/CC administrator.
• To set up a CQ account go to: http://compass.mot.com/web/cqcm
• To download Windows ClearCase go to Engineering Computing (ITIS-EC) http://appsupport.mot.com/SE/ClearCase/
.
• User's Unix ID MUST match Windows login ID (Usually COREID). If you have a different Unix user
ID from your Windows login ID, submit a request at rc.mot.com. For UNIX/Windows userid interoperability issues
1
open a trouble ticket with ITIS-EC who usually will make your UNIX id the same as your
Windows CoreId.
• Pager support at http://compass.mot.com/web/cqcm.
• Submit SR to the CA&M team via the INDEV CQ Database
• For Server/Networking issues, contact the ITIS-EC helpdesk or http://rc.mot.com to open a trouble ticket.
The intended audience is primarily developers who have been assigned a CR. If you need basic training for ClearCase refer to the following:
• ClearCase User Training Class, either online or Rational instructor lead courses available through Motorola University at http://mu.gtss.mot.com/clearcase/
• ClearQuest Training is available online at http://compass.mot.com/web/cqcm
Windows NT, 2000, XP with the standard Motorola image or UNIX SUNOS 4.1.2, Solaris 5.6-10,
RHEL3.0-4.0, SGI IRIX 6.x, or HPUX 10.2 or greater.
1. Issues with userid only.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 6
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
For the sake of clarity, some typographical conventions are necessary. For our guides, we have adopted the conventions used in the manuals from Rational.
Bold Faced Font
This font is used for names you will enter. For example, commands and command names, button names, file names and branch names.
Italic Font
This font is used for variables, document titles, glossary terms, menu option names, and for emphasis.
Courier Font
This font is used for examples of screen output or other prompts.
<Return>
Keystrokes and other keyboard input will appear as above.
[]
Brackets enclose optional items in format and syntax descriptions.
{}
Braces enclose a list from which you must choose an item in format and syntax descriptions.
|
A vertical bar separates items in a list of choices or options in format and syntax descriptions.
...
An ellipsis indicates that you can repeat the preceding item or line one or more times. In certain contexts,
ClearCase will recognize an ellipsis as a wildcard similar to ‘*’ or ‘?’.
If a command or option name has a short form, a dot character indicates the shortest legal abbreviation.
For example: lsc
heckout
This means that you can truncate the command line entry for this command to lsc or any of the intermediate spellings (lsch, lsche, lschec, etc. . .).
Many ClearCase commands allow the user to enter comments to be attached to the event. Useful commenting is highly recommended, and depending on the local environment, may be required by procedure.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 7
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
ClearCase commands that accept comments will accept the following options:
-c
-cfile comment-file-pname
Specifies a text file whose contents are to be placed in all the event records created by this command.
-cq comment-string
Specifies a comment for all the event records created by the command. The comment string must be a single command-line token; typically, you must quote it.
-cqe
Prompts for one comment, to be placed in all the event records created by the command.
For each object processed by the command, prompts for a comment to be placed in the corresponding event record.
-nc No comment. For each processed by the command, creates an event record with no user-supplied comment string.
To mark the end of a comment, press <Ctrl><d>, or enter a period at the beginning of a line and press <Enter>.
The Preface provides an Introduction, References and a Glossary.
Chapter 1 provides an introduction to the CC/CQ Integration with the CR creation and the progression to the completion of the developer activities on the CR.
Chapter 2 provides Rebase Operations and testing phase of the process flow.
Chapter 3 provides the Integration Phase of the CR work.
Appendix A provides examples using the Sandbox VOB.
The paragraphs below contain some key terms that will aid your understanding of the ClearQuest/ClearCase
SCM integration strategy. The terms are listed in alphabetical order. It may be best to refer to these when there is a specific question, rather than just reading them all at once. This is because some background knowledge is necessary for full comprehension of many of the terms.
Artifact
Attribute
Base Contributor
File
A work item or Configuration Item. It can be code or a document.
Attributes are a form of meta-data. Attributes can be assigned to branches, versions and all types of elements. Attributes have a name and a value. Thus, you can assign an attribute to an element and then indicate if that attribute is true or false, or give an integer or string value to the attribute. Attributes are very useful for tying together diverse groups of elements.
Whenever a merge occurs, ClearCase determines a Base Contributor File for the versions being merged. Basically, this is the version of the element that is the closest to being a common ancestor to the versions of the element being merged. During the merge, the elements being merged are compared against the base contributor file.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 8
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Baselines and
Baselevels
Branch
CC
Change Control
Checkin
Checkout
CI
CM
Config Spec
Configuration
Element
CQ
CQCM
DCML
Dependency
Derived Object
(DO)
Dev-Int
Element
GUI
A baseline is a named configuration (version) of a component/product that has been formally reviewed, integrated, tested, and approved. A baselevel is a configuration that has simply been integrated and tested. A progression of baselevels usually culminates in a baseline. So a baseline is more formal than a baselevel and has typically undergone more rigorous formal testing and/or audit and review. In ClearCase, baselines and baselevels are represented using labels. Labels are named tags that can be attached to versions of elements.
The versions of an element are organized into a tree-like structure called a version-tree with branches and subbranches. A branch is a particular line (or path) of development in the version tree for an element. The development line corresponds to the sequential history of changes made along that branch of work.
ClearCase
The process by which a change to a configuration item is proposed, evaluated, approved or rejected, scheduled, and tracked after formal establishment of its configuration identification. [IEEE Std. 610.12-1990]
Periodically you will need to check in an element after modifying it. This is done so that you can build, share changes, submit a CR, etc. . . Checking in an element with the checkin command creates a new version of the element on the branch where it originated from (creates a successor to the element that you checked out). This version is immediately available to anybody whose view includes the branch the element is checked in to.
In order to modify a file or directory, you must check it out of the VOB by using the checkout command. When you check out an element, a place holder is made in the
VOB, and a copy of the element (with write permission) is made in your view-private storage area.
Configuration Item.
Configuration Management.
Each view is driven by a file called a config spec . This is short for “Configuration Specification”. The config spec acts like a filter to determine which version of each element will be presented in the view. The config spec contains a set of rules that determines what version of each element should be selected.
A configuration element is the smallest unit of configuration management and version control. Typical examples of such elements are files and directories.
ClearQuest
ClearQuest Change Management
Document Configuration Management Library system.
A relationship between two changes, where one change relies upon the other change.
Built files and other products as a result of a clearmake compile, are called Derived
Objects, (DO).
Development Integration - a form of incremental integration performed by a development team using a ClearQuest CR and ClearCase branch-type for this specific purpose.
With ClearCase, each file, directory, or other version controlled object is called an element. Every time an element is altered and checked back in ( checkin ), ClearCase ensures that the previous version can still be recreated and accessed. When you create a new version of an element, you don’t overwrite the previous version in the VOB, you supersede it. Thus, all previous versions of an element are retained and can be restored when necessary.
Graphical User Interface.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 9
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Hyperlinks
Labels
Loadline
Mainline
Merge
Metadata
Process management
PCF
Repository
Revisions and
Versions
Version
SCM
TA
Version Control
Hyperlinks are a form of ClearCase meta-data. Hyperlinks are useful for showing relationships between elements. A hyperlink is a logical pointer between two objects. The hyperlink establishes a connection between objects in the same VOB or across VOBs.
Hyperlinks are VOB objects themselves and may be annotated with a text string on either end of the link. Hyperlinks are often used as Merge Arrows to show that two versions of an element have been merged. Merge arrow hyperlinks are created automatically by ClearCase when merges take place.
Another type of meta-data is the label . Labels are applied to versions by users as necessary once the label type has been created using the mklbtype command. To use a label, you just create an instance ( mklabel ).
A variant within a software release for a planned variation of market-specific functionality that must be independently supported, maintained, and configuration managed
A top-level integration branch that serves as the final (and most stable) level of integration for all of its "child" integration branches (typically, each release will have a mainline for each actively developed loadline)
Merging is the process of combining different versions of an element to form a new version of the element. In order for the changes made on one branch to be available on another branch, the element must be merged to that branch. When a merge is completed, a merge arrow hyperlink is made between the merged versions. Merging can be automatic or require user resolution of merge conflicts. Merge conflicts occur when the same section of code has been changed in versions occurring on different branches. One of the most familiar situations where this occurs is when multiple developers are making changes to the same version of an element in response to different CR’s.
The VOB stores file system objects such as source files and derived object files. It also stores informational data that is relational in nature. ClearCase calls this type of data, meta-data . Much meta-data is generated automatically by the system. This includes who-what-why information such as when an element was checked out, when an element was created or modified, build information, etc... Other meta-data can be user-defined and attached to elements manually, or by user-defined processes. Examples of metadata are labels, attributes and hyperlinks.
Ensures the correct flow of software development life cycle steps are followed in a defined sequence by the authorized individuals.
System, Product, Component and Feature_Area . CIs are categorized and organized into SPCFs for the CQ database schema.
A repository is a database which stores and manages elements that are to be version controlled and placed under configuration management.
A revision is the contents of an element at a given point in time. When an element’s contents are modified, or created and then saved in the repository, the result is a new revision of the element. A version is an identifier assigned to a set of one or more revisions of distinct elements. Sometimes the two terms are used interchangeably, but a version can refer to a set of many elements as well as to a single element.
Each time an element is checked in, a new version of the element is created. Versions are stored permanently in the VOB. Versions can be labeled with label types.
Software Configuration Management.
Technical Authority.
Version control provides methods for ensuring that all past versions of source code are accessible. In addition, version control allows all past configurations of source to be recreated. ClearCase is used for version control of source code.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 10
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Version Extended
Pathname
Version Tree
Versioned Object
Base (VOB)
View
View-Private
Storage
To select a version other than the one selected by your view, you can use a version extended pathname . You may indicate a specific numeric version on the file’s version tree, a version which is labeled with a specific version label, or a specific ClearCase label such as CHECKEDOUT or LATEST . Version extended pathnames always include the extended naming symbol (@@).
All versions of an element are organized into a version tree . Version trees are graphical representations of hierarchical tree and can include multiple branches and subbranches.
Each element has its own version tree.
VOBs provide permanent storage for all current and historical versions of source code.
The VOB also contains an extensive database which is the heart of ClearCase’s version control abilities. The VOB database stores records of every change made to each file as well as any changes made to the organization of directories.
Views are windows into the VOB data repository. To access VOB data, you must do so in the context of a view. Your view limits you to seeing only specific versions from the branches that are specified for your view. Dynamic access to the data repository is provided by the view. It is a “virtual workspace” which transparently directs all work to the correct version of each file. There can be any number of views, each named with a unique view-tag. Views are driven by the config spec. Files that are copied into a given view are also stored in view private storage.
When you are in a given view, and you check out an element for editing, the element will be stored on a view server (outside of the VOB). This is called View-Private Storage . View-private storage utilizes space on the local machine (or machine where the view is stored). This is important to remember when checking out large amounts of elements. ClearCase integrates all VOB-resident and view-private elements to form the virtual workspace.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 11
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
CC/CQ integration follows a process defined in CQCM. The following diagram provides a visual explanation of this process flow with respect to the Change Record (CR).
SR unassign (CC, TA) create_CR(AS,CC) reject (CC) unreject (CC) assign (CC) edit(TA, CC) terminal state unsubmit_work(TA, Coord) submit_work (TA) edit(COORD) unclose (Admin) close (Coord)
Closed terminal state
SR
Figure 1-1 CQCM Process flow for CR
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 12
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
The CM Process begins when a Submission Record (SR) is opened. Once the SR is created and assessed, one or many Change Record (CRs) are created and assigned to a Technical Authority (TA). The following roles for this CR phase of the process are described as follows:
• Change-Controller (CC) - Assigns the change-activity to a Technical Authority (TA).
• Technical Authority (TA) - Performs work and submits it for review/test.
• Coordinator (COORD) - Commits the change and closes the CR.
Integrated Flow
In order to perform work on the CR you use both ClearCase and ClearQuest. The integrated flow is shown in Figure 1-2 Technical Authority Development flow . Either a Windows client or a UNIX client can be used to perform various activites related to the CR. The Windows client has a GUI version as well as a command line interface. The UNIX client has a GUI version as well as a command line interface.
The following describes the general flow of this integration:
• An integration between CC and CQ is accomplished by scripts. CC/CQ integration enforces policy through the use of these scripts.
• CC/CQ records information about the progress and state of the work being done.
• All development work must occur on a ClearCase branch that corresponds to an assigned CR.
• ClearCase verifies with ClearQuest that the user creating a branch is assigned to the CR.
Basic requirements needed to run the integration tools include:
• UNIX machine or a PC with ClearCase installed.
• For the latest update for information on the necessary Perl installation versions for the Windows operating system and the UNIX operating system refer to the CQCM ClearCase Administration Guide, COM-
TOOL-CM-UG-004 [7] .
• A CQ client name and password.
• Access to http://cqcmapps.mot.com - the CITRIX server for Windows login to CQ -go to this webpage and follow instructions to setup your user profile for CQ.
• UNIX group permissions set for your group to access files in the VOB. If using Windows CC you must also have access to the Windows group permissions for the VOB area.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 13
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Figure 1-2 Technical Authority Development flow
CR in the
Outstanding State
TA notified of the Assignment mkview
User does not have
Access - No
Checkout allowed
Branch
Allowed?
checkout/ checkin
Rebase
Code?
Fagan
Inspection
ClearCase
Operation
ClearQuest
Operation
Build/unit test CR lock CR branch
TA submit_work
Coordinator links
CR to Actual Target
To Integration
The Technical Authority Development flow on page 14 provides a high-level overview of a typical development CR flow.
The following activities precede the actual CR creation and assignment:
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 14
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
• Open an SR in CQ - this is the initial action that must start before any work activity begins. Any member with a valid account in the CQ database can open an SR.
• Once the SR has been opened, only an Assessor or the Change Controller can create one or many CRs.
The Change Controller assigns a CR to a Technical Authority.
• Refer to online help for learning about CQ and refer to the CQCM ClearQuest User’s Guide, COM-
TOOL-CM-UG-001 [4] for specific information on roles and actions for each actor in the CQCM scenarios.
• The Developer who takes on the CQ defined role of Technical Authority is assigned the CR. The developer is notified of the CR by an email.
• At this point the CR has been created and assigned. This begins the start of the CR lifecycle which corresponds to the ClearCase portion of the CQCM process. The developer uses CC and does not return to CQ until all work activities on the CR are completed.
Figure 1-3 A CR in the Assigned state
The screen shot above shows that the Change Controller has assigned the CR to the Technical Authority
(TA). Next the developer creates a view.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 15
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
UNIX or Windows Command Line procedure:
The creation of a ClearCase view is typically created through the mkview script. This script simplifies the view creation process and provides the following benefits:
1. Automatically creates the branch type in the ClearCase VOB
2. Automatically generates the view config_spec with the proper config_spec rules based on the specified baseline label
3. Automatically creates the view in a pre-designated central view storage location (If multiple view storage locations have been defined, the mkview script shall use the location with the most available disk space)
4. Automatically assigns and enforces view and branch names that conform to CQCM naming conventions mkview can be used from either the UNIX or Windows command line (On Windows, run mkview.bat) .
Syntax: mkview {-cr <CR ID> | -br <branch name> | -tag <view tag> }
{-b <baseline label>}
NOTE: To get a complete list of options refer to the online help by typing the <command> -h at the command prompt.
Typically, mkview with the -cr and -b options are the most common arguments used with mkview. Mkview requires the -b <baseline label> in order to properly generate config_spec rules that are based on the specified baseline label. By specifying the cr <CR ID> argument, mkview will automatically assign a branch name and view name that conforms to CQCM naming conventions. If the CR has a Target_Type of
“ Dev-Build ” or has a CR_Usage of “ Dev-Integration ” then, by default, the resulting branch name will not contain a release name and will be of the form: dev-<CR#> devint-<CR#>
(for a Development CR, e.g.: dev-123)
(for a Dev-Int CR, e.g.: devint-456)
Otherwise, the CR branch name may take on two different naming conventions depending on the release and/or loadline combinations for the CR.
1. <release#>_dev-<CR#> (e.g. r16.1_dev-123, r16.3.1_dev-456)
2. <release#>-<loadline#>_dev-<CR#> (e.g. r16.1-mkt1_dev-123, r16.3-mkt4_dev-456)
Where
<CR#> - truncated CQ CR number without CQ database identifier and no leading zeroes
<release#> - multi-digit release number that corresponds to the "Predicted Release" of the CR in
ClearQuest. This numeric release number must be prepended with the "r" character and may contain multiple decimal points that separate the release digits. (e.g r16.1, r16.3, r16.3.1, r17.0)
<loadline#> - loadline number that correspond to a unique loadline name in ClearQuest. For each loadline market name in ClearQuest, a unique loadline number in ClearCase has been assigned to represent this loadline. Each known loadline market number has been assigned a number starting with #1 and sequentially incremented by 1. In ClearCase, the loadline numbers must also be prepended with the "mkt" string designation. (e.g.
mkt1, mkt2, mkt3) Refer to the WSG CMBlueprint Multiple Loadline Management
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 16
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Process, WSG-PROC-CM-PROC-014 [8] , for more information regarding the loadline naming conventions and a mapping of the loadline names in ClearQuest to the loadline market numbers in ClearCase.
The CR branch need not specify the release number for current development releases (where the release mainline is the main branch in ClearCase). Similarly, the loadline number is not required for releases where no loadlines have been designated or if the CR is targeted to the ’ global ’ loadline. The examples above illustrate branch naming formats where the release and/or loadline numbers may or may not be required.
The following table also further defines some of loadline name and loadline number mappings that have been currently been designated.
Loadline Name global vpu ivpu linuxdev nodeb crnb mm2 ubs ipbscdo beta sprint verizon alltel kddi china tuka sdu wibb atca mms sms mms2
Loadline Number
N/A mkt52 mkt53 mkt54 mkt55 mkt56 mkt57 mkt58 mkt59 mkt0 mkt1 mkt2 mkt3 mkt4 mkt5 mkt6 mkt51 mkt60 mkt61 mkt70 mkt71 mkt72
Example branch name r16.3_dev-1234 r16.3-mkt0_dev-1234 r16.3-mkt1_dev-1234 r16.3-mkt2_dev-1234 r16.3-mkt2_dev-1234 r16.3-mkt3_dev-1234 r16.3-mkt4_dev-1234 r16.3-mkt6_dev-1234 r18.0-mkt51_dev-1234 r18.0-mkt52_dev-1234 r18.0-mkt53_dev-1234 r18.0-mkt54_dev-1234 r18.0-mkt55_dev-1234 r18.0-mkt56_dev-1234 r18.0-mkt57_dev-1234 r18.0-mkt58_dev-1234 r18.0-mkt59_dev-1234 r18.0-mkt60_dev-1234 r18.0-mkt61_dev-1234 r18.0-mkt70_dev-1234 r18.0-mkt71_dev-1234 r18.0-mkt72_dev-1234
The view name for the corresponding CR branch shall also be named the same as the branch name with the exception that the view name shall have the username prepended to the CR branch name. (e.g.
acruz1_r16.3.1_dev-456, ahollan1_r16.3-mkt4_dev-456)
Devprojects
Devproject is the development project attributes and is associated with the CR number. If it does not associate the attribute tag, then the user will be prompted to select from a Devproject as shown in the example below. It is always recommended to answer NO at the Devproject prompt as shown below, or it will automatically fill in your config spec file with the devproject information.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 17
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
The -b baseline option allows you to point to either the latest baseline or baseline associated with the baseline that has been targeted by your group’s build integrator. If your local admin has set up the baseline(s) to be targeted by your group the script looks for the latest tag and uses that. If this has done been set up by your local admin then when you run the mkview command, if you don’t enter a baseline it will prompt your for a baseline. Note that you should always use the naming conventions for your group’s baseline or else you could be doing builds off the wrong baseline names. Contact your local expert or local admin for the correct naming of labels.
Example:
$ mkview -v CDMA -cr 277 -b SCMTEST_R16.1_REL-01
In this example the vob Family is CDMA, the CR number is 277 and the baseline target is
SCMTEST_R16_REL-01.
If this is the first time a user uses ClearCase and ClearQuest together, they will be prompted to enter their
ClearQuest Username and Password when the branch type is created. This happens as well if the user’s
ClearQuest password changes.
Note: The ClearQuest username is defaulted to the current UNIX / Windows user. So you don’t need to re-enter your Clear-
Quest username by default.
A Developer creates view using latest build project file using the mkview command. Based on the Branch name, the triggers in ClearCase will attempt to enforce policies. For example, branch prefixes: dev-, int-, tmp can be used to determine whether or not ClearQuest is queried for information, or if multiple people can integrate and push their changes.
Note: You only need to enter the number portion (e.g.INDEVxxx).
Note: To display a list of all Assigned CRs for current user, you may enter the following mkview command or alternative mkbrtype command with an invalid CR: mkview -cr “?”
- OR cleartool mkbrtype -global -nc dev-1
Example using the mkview command - UNIX
----------------------------------------
1. Use the CR number, in this example 529.
$ mkview -br r16.3_dev-529 -b SBOX-PRE1.0-02
Note for Windows Command prompt >mkview -br r16.3_dev-529 -b SBOX-PRE1.0-02
Do you want to associate the view with a DevProject? (y/n)y
Please enter your CQ username [qa1120]:
Note: If you don’t enter any character and just press <Enter> on the keyboard, the CQ username will be defaulted to the current user as displayed in the command line prompt.
Please enter your CQ password:
Note: This username and password information is stored in your home directory in newly a created .cqparam file which encrypts the password. If for any reason your password changes you should remove this file and go through the process again to produce a new .cqparam file with the new password.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 18
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Do you want to associate the view with a DevProject? (y/n)y
Select from list of DevProjects
1) Main.prj
2) SBOX-PRE1.0-02.prj
3) SBOX-PRE1.0-01.prj
4) SCMTOOLS-PRE1.0-02.prj
5) SCMTOOLS-PRE1.0-01.prj
2. Select which DevProject you wish to associate the view with. Enter a value from 1-5, or 0 to Cancel:
2
Created branch-types: r16.3_dev-529@/usr/vob/sc/sbox
Created view qa1120_r16.3_dev-529
view storage is /usr/prod/sc_view11/cmbp/r16.3_dev-529.vws
########## Config-spec for view qa1120_r16.3_dev-529 ##########
#----------------------------------------------------------------------#
# CMBlueprint - ClearCase View Config Spec
# (Using DevProject 'SBOX-PRE1.0-02' located at:
# /usr/test/scmtool/test/cmbp2.0/cm-policy/bin/../config/CSD_DE_projects/SBOX-
PRE1.0-02.prj)
# Development rules: element * CHECKEDOUT element * .../r16.3_dev-529/LATEST mkbranch r16.3_dev-529 element * SBOX-PRE1.0-02
# Base rules for DevProject 'SBOX-PRE1.0-02':
# element * SBOX-PRE1.0-02.1
element * /main/LATEST
#----------------------------------------------------------------------#
3. Set to newly created view
$ cleartool setview qa1120_r16.3_dev-529
4. Edit or create new file.
$ cleartool co home.c
Created branch "r16.3_dev-529" from "home.c" version "/main/2".
---excerpt - actual screen output may vary --------
Checked out "home.c" from version "/main/r16.3_dev-529/0".
5. You have successfully checked out the file.
In the example above the user has successfully checked out the file home.c
from the ClearCase VOB.
If the Windows ClearCase user creates a view using the view creation wizard, they should adhere to the view naming convention that is: username_branchname for CR branch.
If the branch type does not exist, the checkout operation will fail. If the user is not the authorized TA the operation will fail.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 19
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
If the user does not associate a Windows ClearCase View profile to the view they are creating, then the branch type will need to be created manually either by running the cleartool mkbrtype command or by using the ClearCase Type Explorer. The config spec will also need to change to what mkview.pl produces.
The user’s config spec should contain a rule that uses the mkbranch branch name in it. Upon a checkout or a mkelem operation rule, ClearCase will automatically create the user branch on any element that does not already have the branch.
For more information on using Windows ClearCase: ClearCase Concepts and Reference Guide, COM-
TOOL-CM-REF-001 [6] .
In the next phase of the flow, (corresponding to Step 5 above) you may proceed to modify the code by issuing a cleartool checkout command from the command line, or from Windows Explorer by right clicking on the element or selecting the checkout button.
Upon completing modifications, it is recommended that all files and folders modified on your branch should be checked in to the VOB. The cleartool lsco –avobs –me –cview performs this function. You can also use the Windows tool “ Find Checkouts ”.
After the work is done on the file and it is checked in, the next phase of the flow is to determine whether you need to rebase the code.
CQCM provides a command line tool, ccContact, to contact CC admin(s) of a vobfamily by sending email and/or page. The configuration files must be preconfigured by local CC admin in order to use this tool.
It will prompt the user for the following seven fields displaying default value (wherever applicable).
1) User ID
2) Hostname
3) View Name
4) Phone number
5) Email address
6) Problem Description
7) Error Log ccContact will send the above information to the CC admin(s) associated with the vobfamily.
Example using ccContact command - UNIX
--------------------------------------view: scStartSCM6 -> ccContact
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 20
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Please provided information for the following. Default is in []
User ID? [userid]:
Hostname? [csdbld02]:
View Name? [scStartSCM6]:
Phone Number? : 12345
Email address? : coreid@email.mot.com
Problem Description? (Hit CTRL-D to finish)
(Please press "enter" for each screen line of your input - there is 256 characters per line limit) : mkview fails for CR # MOTCM00573726 (even after removing the branch type)
Error Log? (if not applicable enter N/A and Hit CTRL-D to finish)
(Please press "enter" for each screen line of your input - there is 256 characters per line limit) :
Error: You already have an active CR branch associated with this CR(MOTCM00573726). You can not create a new CR branch until this CR branch type is deleted or obsoleted.
Do you want to page? (n) y
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 21
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Typically, development views are based on a given ClearCase baseline version of the product. In ClearCase, baseline versions of a product are normally designated by labelled versions of each element (file or directory) of a given VOB or VOB family. ClearCase baselines or labels are usually coordinated and released by product integrators that apply a given baseline label to each element in the VOB so that ongoing development may use this label as a basis for future CR development.
Issues may occur if ClearCase developers use an older baseline label for their CR development views.
Since older baseline labels may not reflect the latest integrated CR modifications to the product, the likelyhood of merge conflicts increases. The concept of rebasing a view allows a ClearCase user to update his/her view in order to "see" the latest changes from the latest baseline versions of all elements in the
VOB. By rebasing one’s view, merge conflicts shall be resolved in the individual developer’s CR view rather than within the integration view. Rebasing within a CR view also allows the CR developer to build and unit test the integrated changes before merging the changes to the integration branch.
Rebasing within a view promotes reuse of existing CR branches. Rather than "merge out" versions on a
CR branch to another branch, only the version differences are "merged in" onto existing element CR branches.
You should also consider whether related CRs are being re-baselined. For example, you may be working as part of a team to implement a feature. If you are doing a feature integration based on a particular label, you may want to make sure the CRs have not been baselined to a more recent baseline.
The process of rebasing a view consists of two steps in ClearCase:
1. Update view’s config spec with new baseline label
2. Merge the element differences between original baseline and new baseline (if necessary)
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 22
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Step 2 is required if ClearCase CR development (checkout, checkin, mkelem) is already in progress within the view. Typically, a CR development branch is automatically created from the given baseline label in the view’s config spec at the time of the initial checkout of an element. ClearCase checkouts of any element before the update to a baseline label in the config spec remain with the CR branch rooted at the version indicated by the original baseline label.
By merging after an update to the view’s config spec with a new baseline, only the elements that have been modified on the CR branch will be possibly affected. The following conditions determine whether Clear-
Case merges a given element as specified in Step 2 of the rebase process:
• CR branch exists
• CR branch based off of original baseline label version
• Element version labeled with new baseline label different than original baseline label
To minimize the number of elements merged, any initial checkouts of element versions (version 0) may be unchecked out prior to merging new baseline changes. NOTE: This assumes that CR branches are removed automatically by uncheckout trigger for zero version branches.
Consider the following example config spec for a CR view that uses auto-make branch rules to force CR development on an individual CR branch: element * CHECKEDOUT element * .../ r16.3_
dev-1234/LATEST mkbranch r16.3_
dev-1234 element * SDU_PRE16.3_REL-05 element * /main/LATEST
Upon a checkout of an element, the rules specified by this config spec initially creates a r16.3_dev-1234 branch from the element version indicated with the SDU_PRE16.3_REL-05 label. This auto-creation of the CR branch can be shown pictorially below in Figure 2-5.
Figure 2-4 Example element version tree after initial checkout
/main
SDU_PRE16.3_REL-05
/r16.3dev-1234
1
SDU_PRE16.3_REL-10
It is recommended to check in all elements prior to the merge in order to distinguish work done prior to the merge and what resulted from the merge.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 23
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
If the ClearCase user now decides to rebase the current CR view to the most current baseline label
(SDU_PRE16.3_REL-10), the developer must initially update the view’s config spec with this new baseline label: element * CHECKEDOUT element * .../r16.3_dev-1234/LATEST mkbranch r16.3_
dev-1234 element * SDU_PRE16.3_REL-10 # Changed element * /main/LATEST
The view’s config spec may be modified using standard ClearCase commands such as cleartool edcs.
By updating the view’s config spec with a new baseline label, all element versions that are dynamically shown within the view shall be the versions that are labeled with the new baseline label
(SDU_PRE16.3_REL-10). The only exceptions are elements that may contain CR branches (r16.3_dev-
1234) created prior to updating the config spec with the new baseline label. Since ClearCase uses topdown precedence rules for config specs, the latest version on the CR branch (r16.3_dev-1234) always takes precedence over a version specified by the baseline label. Similarly, other branches that are referenced in the view’s config spec above the baseline label, always takes precedence over the version specified by the baseline label.
For elements with pre-existing CR branches (r16.3_dev-1234), the modifications to these elements from baseline label SDU_PRE16.3_REL-05 to baseline label SDU_PRE16.3_REL-10 must be merged into the
CR branch (r16.3_dev-1234). This may be accomplished by executing the following cleartool findmerge command or the scBRMerge command with the -rebase option: cleartool findmerge -avobs -fver <NEW BASELINE LABEL> -gmerge -merge
- OR scBRMerge -rebase
For example: cleartool findmerge -avobs -fver SDU_PRE16.3_REL-10 -gmerge -merge
- OR scBRMerge -rebase
Note: For ClearCase versions prior to v4.0, you must use the -graphical option rather than the -gmerge option.
Figure 2-5 Example element version tree after rebase merge
/main
SDU_PRE16.3_REL-05
/r16.3_dev-1234
SDU_PRE16.3_REL-10
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 24
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Once you’ve completed the rebase procedure (if it was deemed necessary), you are ready for the next phase of the CR development activities, Build and Unit Testing. At this point in time you should conduct your peer reviews and/or Inspections. The ClearQuest review records may now be submitted and performed prior to performing the CR.
At this point in time you should attempt to build your code in your view work space to conduct Unit Testing as needed. Record your results in your CR.
If upon testing or compiling there are errors/defects found they should be recorded and fixed in the code.
This means checking out the files again in ClearCase and then checking them back in. Depending on the amount of changes another inspection maybe necessary before proceeding to Build and Unit test your branch files.
It is recommended that your group does a clean build prior to inspection.
Figure 2-6 Tester signoff of testing/review/inspection results and description field
Figure 2-6 above illustrates the Tester tab on the CR form.
After ensuring that the work has been completed and tested on the CR, it may be submitted in ClearQuest tab as performed.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 25
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
When you run the cleartool lock command, you signal the ClearQuest CR that you have finished work on the branch. A trigger in ClearCase updates the ClearCase tab on the CR in ClearQuest with information on the files included in the branch created in ClearCase. Be sure to test before you lock the branch. For more information on locks refer to Rational ClearCase Manuals, Version 4.0 (http://scm.gtss.mot.com/ rationalman.html) [5] .
To lock your branch type so no more changes can occur to it, use the following command:
Syntax: lock [-rep.lace] [-nus.ers login-name[,..] | -obs-olete ]
[-c comment | -cfi.le comment-file-pname]
The following is a simple example which locks the development branch dev-529:
cleartool lock –rep brtype:dev-529
Once you have locked your branch go the CQ CR form, and verify that under the CC tab on the CR, it states WORK_COMPLETED . This indicates that the branch was locked successfully and submit the fact that you have completed work on the CR. This submit_work action sets the CR to the Performed state as shown in Figure 2-7.
Figure 2-7 Submit Work Form in CQ
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 26
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Figure 2-8 CR set to Performed state
At this point the work, as shown in Figure 2-8, on the development CR is complete and the next phase, that of integration, begins.
The re-assignment of a CR to a different Technical Authority (TA) may have various impacts in ClearCase.
This section attempts to describe these impacts and how they may be handled. The re-assignment of a CR in ClearQuest shall not be covered in this section and it shall be assumed that the re-assignment to a new
TA in ClearQuest has been completed prior to following these procedures for ClearCase.
The primary issues regarding the re-assignment of a CR are:
• CR branch type ownership will not allow new TA to lock CR branch type
• CR branch type locked except for current user and VOB admin
• CR view owned by original TA and may not be writeable by new TA.
To avoid view write permissions problems, it is recommended that a new view be created for the newly assigned Technical Authority (TA) of the CR. If the view is created successfully with the proper config_spec rules, the new view shall be able to reference any existing checkedin versions for the given CR branch.
ClearCase, by default, uses different levels of permission checking that may vary depending on the intended action of the user. A user’s action of checking out an element for a CR branch in a given view may involve several steps that ClearCase processes in the following order:
1) If the CR branch does not exist, the auto-make branch rules in view’s config_spec shall attempt to create the CR branch instance in the element. Permission to create a branch in an element is contingent on the user being one of the following: element group, element owner, VOB owner, or root.
2) ClearCase now attempts to checkout the next given version on the CR branch. The user must be one of the following to be able to checkout: element group, element owner, VOB owner, or root.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 27
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
3) Upon a successful checkout of a version of an element in the VOB, ClearCase proceeds to attempt to write a view-private copy of the checked out version into the user’s view. The default permission of a view is established during the creation of the view. For UNIX views, the view’s write permission level is determined by the user’s umask setting.
In addition to the default permissions that ClearCase enforces, the CQCM ClearCase toolset enforces the following additional permission restrictions:
1) Mkbrtype post-trigger - Locks the CR branch type except for current assigned TA and VOB administrator
2) mkview script - By default, creates development CR views with write permission only for the current view owner (assigned TA). If the “ share_vw ” option is given to mkview, the view shall be created with write permission to owner and group. The mkview script also automatically calls mkbrtype to create CR branch type.
Re-assignment of CR Branch Type
Assuming that the newly assigned TA is a member of the ClearCase VOB group, the re-assignment of a
CR to another TA may require the following two actions by the original TA. These actions may also be performed by the VOB Administrator if the original TA is not available to perform these actions.
1. The CR branch type ownership (using cleartool protect) must first be transferred to the new TA. The cleartool protect command can only be executed by the branch type owner (original TA) or the VOB administrator. cleartool protect -chown <New TA> brtype:<CR branch>@vob:<VOB> where:
<New TA> - The username of the newly assigned Technical Authority (TA)
<CR branch> - The CR branch type name
<VOB> - The VOB tag where the CR branch type exists
NOTE: If an administrative VOB has been set up by the VOB administrator(s), the <VOB> parameter shall be the VOB tag of the administrative VOB. Otherwise, if an administrative VOB is not used, the cleartool protect command must be executed for each branch type instance in every VOB that the branch type exists.
Example: cleartool protect -chown rlee1 brtype:dev-1234@vob:/vob/testvob
2. The CR branch type must be unlocked or the lock replaced with the new TA’s username in the exclusion list. The cleartool lock and cleartool unlock commands must be performed by the lock owner (original
TA) or the VOB adminstrator. NOTE: The transfer of branch type ownership (cleartool protect) must be executed prior to the replacement of the lock (cleartool lock). Otherwise, the lock will prevent the successful execution of the cleartool protect command.
cleartool lock -rep -nusers “<username list>” brtype:<CR branch>@vob:<VOB>
- OR - cleartool unlock brtype:<CR branch>@vob:<VOB> where:
<username list> - list of user names that are excluded from the lock. This list should include the new
Technical Authority and the VOB Administrator.
<CR branch> - The CR branch type name
<VOB> - The VOB tag where the CR branch type exists.
NOTE: If an administrative VOB has been set up by the VOB administrator(s), the <VOB> parameter shall be the VOB tag of the administrative VOB. Otherwise, if an administrative VOB is not used, the cleartool protect command must be executed for each branch type instance in every VOB that the branch type exists.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 28
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Examples:
$ cleartool lock -rep -nusers “rlee1,scscm” brtype:dev-1234@vob:/vob/testvob
- OR -
$ cleartool unlock brtype:dev-1234@vob:/vob/testvob
The following are various TA re-assignment scenarios and the actions required for each of these scenarios:
1. CR branch type and view not created.
No additional action required. Re-assigned TA creates view/brtype using normal procedures.
2. CR branch type and view created, but no development started in ClearCase
Branch type ownership must be transferred to new TA (cleartool protect). Lock on CR branch type must be replaced or removed (cleartool lock/unlock). These actions are described in more detail in previous section and can only be executed by the original TA or VOB administrator.
3. CR branch type and view created (development started in ClearCase, but no elements checkedout)
Same resolution as in scenario 2 above.
Branch type ownership must be transferred to new TA (cleartool protect). Lock on CR branch type must be replaced or removed (cleartool lock/unlock). These actions are described in more detail in previous section and can only be executed by the original TA or VOB administrator.
Once the lock has been replaced or removed, the new TA of the CR may now continue to create a new CR development view following the normal view creation procedures.
4. CR branch type and view created (development started in ClearCase and elements checkedout in original TA’s view)
The original TA should be initially contacted to have this user determine whether the currently checkedout elements should be checked back into the VOB or uncheckedout. If the original TA is inaccessible, the
VOB administrator may be contacted to checkin or uncheckout the checkedout elements in the original
TAs view.
Once all checkedout elements have been checkedin (or uncheckedout), the same actions as in scenario 2 above may be used to change the branch type ownership and remove/replace the lock on this existing branch type as described below:
Branch type ownership must be transferred to new TA (cleartool protect). Lock on CR branch type must be replaced or removed (cleartool lock/unlock). These actions are described in more detail in previous section and can only be executed by the original TA or VOB administrator.
Once the lock has been replaced or removed, the new TA of the CR may now continue to create a new CR development view following the normal view creation procedures.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 29
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
CR dependencies are represented in CQ by linking two (2) CRs together (parent-child relationship). This relationship represents that all the children CRs must all be closed before the parent can be closed. From the ClearCase perspective, the parent child relationship represents that all the children CRs must be integrated before the parent CR can be integrated.
To create a parent-child dependency in CQ, you need to execute the following steps:
1. Execute an action edit on the parent CR.
Take an Edit action
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 30
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
2. Once in Edit mode, click on the Link CR button. A new window will popup. On the Browse Record
Type Development_CR window, enter the child’s CR number in the Enter Key field. Press the Search button then click on the CR number in the Results field.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 31
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
3. Final step to create the CR-CR dependency is to press the Apply button. All the child CRs for the parent CR will be listed in the Child CRs section.
Child CR attached to Parent CR
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 32
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
The integration phase includes combining one or many CRs into an integration build. For complete information on Build strategies and philosophies refer to reference WSG CMBP Software Build Process, WSG-
PROC-CM-PROC-001 [3] .
After the CR has been set to the Performed state by the developer the Coordinator receives an email stating that the TA has performed the CR.
The Coordinator then opens the CR form in ClearQuest and depending upon the type of integration build, selects a target type. Refer to Figure 4-2 Coordinator selection form for target fields for an example of this CQ form.
The integration phase of the CR process begins with the start of integration and ends with the hand off to
Systems Test (SST). Depending on the choice between the push or pull model of merging techniques each group uses, the tools used vary.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 33
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Figure 4-1 Integration Process Flow
Start Integration scMergelist
-add pull integration ?
no yes
Developer Merges code. Ensure that scBRMerge is run.
Authorized User runs scMergeList
Integrator merges branch using scMergeStat and scBRMerge
Verify Content of Build
Run: Tracemerge
Build Code
Label Build
Coordinator
Closes CR
Hand-off to SST - testing
ClearCase
Operation
ClearQuest
Operation
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 34
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Figure 4-2 Coordinator selection form for target fields
The Coordinator selects the Target Type ( Package, SCM-Build, Int-Build, Dev-Build, Ext-Build, or
Patch-Build ) as shown above.
The Coordinator selects the Actual Target build that this branch will be built in prior to the build as shown below. This will correspond to a ClearCase label.
Figure 4-3 Form showing the Actual Target which is a CC label.
.
Development merging of branches is performed using a push or pull type approach to integration builds.
In the push model, developers are responsible for merging their branches onto the integration branch. In a pull model, it is the integrator who successfully merges various developers’ branches. The developers use the push model when they want to merge their changes to a common integration branch. The Integration
Builder would use the pull model when they query to find out what branches need merges to a particular integration branch. They then run a merge tool to pull the changes into the development branches or other pre-integration branches together into their integration branch. Figure 4-4 Using View Profiles - Finish
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 35
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Private branch to a Push model. shows the Windows Option dialog for Finishing a private branch and the
Version Tree Browser window.
Figure 4-4 Using View Profiles - Finish Private branch to a Push model.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 36
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Figure 4-5 Example of Pull Merge from integration branch to \main branch
The CA&M Applications team developed the following set of tools to help developers and integrators merge code: scMergeList, scBRMerge, mergestat, tracemerge .
• scMergeList – gives development branch permission to merge into an integration build view or branch.
Only a certain set of users have permission to run this command usually the change controllers and integrators/builders.
scMergeList {-a.dd | -s.ub[tract]} {-f.branch <From-Branch> [-t.branch <To-
Branch>] [-ffm.ail | -noffm.ail] [-v.family <vobfamily>]
- OR scMergeList {-a.dd | -s.ub[tract] | -sy.nc} {-b.aseline <Baseline_Record> } [t.branch <To-Branch>] [-ffm.ail | -noffm.ail] [-v.family <vobfamily>]
Once an CR has been moved to the Performed State and the branch type locked, you are ready to perform a merge. The scMergeList command is run to mark the branch as targeted to a particular integration branch and has permission to merge. The scMergeList command may be executed for CRs in the Assigned or
Performed state, but the CR branch cannot be merged using the scBRMerge command until the CR has been Performed.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 37
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
The tool enforces the policy of merging within a particular load line, baseline and release. When the CR is in the Performed state, the Coordinator enters the Actual_Target field. The coordinator should then run the scMergeList -a.dd
with the –b.aseline option the tool will query ClearQuest database to find all CRs associated with the baseline in the Actual Target field and then mark them “OK_to_merge” . The sy.nc
option is may also be used with the -b.aseline
option and is similar to the -a.dd
option with the exception that it will also automatically remove CR branch merge permissions if the CR does not have a matching baseline in the Actual Target field of the CR. This ensures that the CRs with the Actual Target baseline matches the CR branches that have also have merge permission.
Usually the owner of the build view runs scMergeList –add branch name command, which will mark the branch type with the OK_to_Merge hyperlink.
The developer is permitted to merge their changes, with the scBRMerge command.
If the merge operations are successful, the branch is marked Merge_Ready_to_Build by the scBRMerge command. Here is an example where the integrator is running this command in the sbox_pre16.3_int-11 view: scMergeList -sync -b SBOX_PRE16.3_INT-11
If DEPENDENCIES is turned on for the vob family, all the child CRs branches must either have permission to merge or in the closed state, before the parent CR branch can be given permission to merge.
• scBRMerge – can be used to merge between any branch type. The most common use is when merging from a development branch to an integration branch. scBRMerge is a wrapper that uses cleartool findmerge . If merging to an integration branch the user must have permission to do so, scMergeList must be run first.
The scBRMerge command can be used to merge any branch type. It is required for all Integration and Dev-
Int branches, and recommended for developer branches that are merged to other developer branches.
scBRMerge does not require the use of scMergeList when merging between two dev branches.
Note: Since Windows ClearCase also has some Merging tools, we recommend that for traceability that the scMergeList and scBRMerge command still be used after the merge to ensure the proper metadata is attached for future integration work.
scBRMerge [ -print ] [ -nong | -nongraphical ] -f.branch <from_branch>
[-c.merge] [-d.elta] [-query] [-noci]
- OR scBRMerge -r.ebase [-ba.seline <BASELINE_LABEL>] [ -print ] [-nong |
-nongraphical ] [-c.merge][-query] [-noci]
Windows users can also run scBRMerge on the Windows command line. It performs a validation by searching for all branches that have been merged into a view.
Only elements requiring a merge will be merged. If any elements have conflicting changes then the graphical merge tool will be launched. If the -nongraphical option is given, then the merges shall be executed using ClearCase merge tool non-graphically instead of through the GUI.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 38
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
If the -print option is used, a report is generated of elements needing a merge, but no merge is performed.
This allows the user to determine a list of elements that will be merged prior to actually performing the merge.
The source and destination branches for the merge must always have compatible releases and loadlines.
That means that for anything except tmp branches, the release (and loadline) of the source and destination branch must much. If either branch corresponds to a CR in ClearQuest, then the corresponding release and loadline to match against is taken from the CR rather than the branch-name.
The table below indicates the additional rules and conditions for merging a branch to an “active” Integration branch or Dev-Int branch. Note that this is in addition to any release compatibility constraints and in addition to any OK_to_Merge and FeatureID constraints (see the section on Configuring a Dev-Int CR branch ).
Figure 4-6 scBRMerge Source and Destination Branch Compatibility
Merge Source Branch
Branch Type
CR Target
Type
Dev-CR
Branch
Dev-CR
Branch
Dev-Int
Branch
Int-Build
Patch-Build
Dev-Build
Int-Build or
Patch-Build or or
Dev-Build
CR State
Assigned
Performed
Closed
Assigned
Performed
Closed
Assigned
Performed
Closed
Integration
Branch
Temporary
(tmp) Branch
N/A
N/A
N/A
N/A
Merge Destination Branch
Allow merge to
Dev-Int branch?
Yes
No
No
Yes
Yes
No
No
Yes
Yes (rebase)
Allow merge to
Integration branch?
No
Yes
No
No
Yes
No
No
Yes
No
Yes Yes
Yes Yes
The -cmerge option allows certain element types to be executed as a "copy merge". These specialized element types must be initially configured by the VOB administrator, but once configured, allow individual users to override the default merge behavior for these element types by executing a "copy merge" rather than an actual merge for the element. An element that is "copy merged" copies and overwrites the target version of an element from the source version. The resulting new version created is an exact copy of the version from the source version that it was merged from.
Set into your integration view or development view by pointing to the integration branch.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 39
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
The -delta option now allows users to use scBRMerge in order to perform a “delta” or “insert” merge of only the changes on a given branch. This delta merge option overrides the default ClearCase merging heuristic and forces only scBRMerge to behave in the a fashion where only the delta changes on a given branch is merged. This is also the default merging logic that is used when the portCR tool is executed.
The -query option will query user for all code changes during and automatic non-trivial merge. ClearCase’s default behavior is to automatically merge these changes but with this option user can overide this behavior and select each change manually for each file.
The -noci option will leave all the merged elements checked out. This option cannot be used on the integration branch.
• tracemerge – performs a validation by searching for all branches that have been merged into a view.
tracemerge [–b <branch name> ] [–l <# levels to trace>]
The tracemerge utility program performs a search for all branches that have gone into a view and displays a list of branches that have been merged into the view. The user must be set to a view and inside a VOB directory to run the command. The user should specify the branch name on the command line to indicate where to start the search.
This tool is part of the release packaging process to get a listing of all CRs for an integration branch to see if they have been merged or not merged.
• mergestat can be run by the integrator at a future time to find out what the status of a branch is and to report on what CRs or merged, or not merged. The status can be OK_to_Merge as well as
Merged_Ready_to_Build.
mergestat [-a|-n] [-s.ort] [-l.ong] [-r.aw [-d <delimiter char>]] [-b <branch>]
[-v <vobfamily>] [-h.elp]
The mergestat report has also been expanded to query for ClearQuest CR information using the -long and
-raw options. Additional information such as the Comp/FA, TA, CR#, SR#, and Headline can also be shown with these new mergstat options.
If DEPENDENCIES is turned on for the vob family, all the child CR branches must either be integrated into a build branch or the state of the CR be closed, before the parent CR can merge into the integration branch.
Testing the Merge
1. The Builder attempts to perform the build.
2. If all Merges were successful but the merge operation breaks the build, the Developer is notified that the build failed and needs to be fixed. If the fix can not be made cleanly on the integration branch, a new CR must be created and assigned to the TA to fix the problem files. These files will then be associated with this new CR and will be merged into the integration branch.
The Merge State feature provides a mechanism of managing the merge status within the ClearQuest CR record in order to enforce additional rules and restrictions in ClearQuest and in ClearCase. Previously, the
CR traceability of the ClearCase CR development that was recorded in CQ ended once the CR branch type was locked from further development. The Merge State functionality extends the existing CQ/CC integra-
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 40
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________ tion by recording in ClearQuest the status of the CR as moves though its integration lifecycle. In ClearQuest, the CR record will now reflect the current ClearCase integration status. These integration statuses will indicate to the CQ user whether the CR has been "Targeted to a build, but CR development not completed",
"Targeted to a build and CR branch locked", and "CR merged onto an integration branch". In addition, the specific integration branch is also recorded as well as the CR integration status. Recording the completion of a successful CR merge to an integration branch also allows CQ queries to be developed that help coordinators properly associate the correct list of CRs to a given baseline build.
Figure 4-7 Typical SW CR Development Lifecycle
WORK_STARTED lock brtype:<CR branch> scMergeList
-add
WORK_TARGETED:
<Integration Branch>
WORK_COMPLETED scMergeList -add lock brtype:<CR branch>
WORK_COMPLETED:
<Integration Branch> scBRMerge
WORK_INTEGRATED:
<Integration Branch>
The figure above depicts the typical CR development/integration lifecycle and the state values that are recorded in the ClearQuest CR cc_change_set field.
With the introduction of the Merge State feature, the Merge Management Tools have been modified to update the CR cc_change_set field with the additional state values that may be used to easily determine the integration status of a CR. The following table describes the Merge State transitions and explains the definition of each these state values. For Dev-Int CRs and branches, refer to the section Development
Integration with Dev-Int CRs & Branches .
Clearcase
Action mkbrtype scMergeList -add previous CR cc_change_set value
N/A
WORK_STARTED current CR cc_change_set value
WORK_STARTED
WORK_TARGETED:
<Integration Branch>
Description
Creation of initial CR branch type updates state to WORK_STARTED
WORK_TARGETED indicates that
CR brtype is NOT locked (CR in
Assigned state), but is targeted to an integration build
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 41
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Clearcase
Action lock scMergeList -add lock scBRMerge previous CR cc_change_set value
WORK_STARTED
WORK_COMPLETED
WORK_TARGETED:
<Integration Branch>
WORK_COMPLETED:
<Integration bBranch> current CR cc_change_set value
WORK_COMPLETED
WORK_COMPLETED:
<Integration Branch>
WORK_COMPLETED:
<Integration Branch>
WORK_INTEGRATED:
<Integration Branch>
Description
WORK_COMPLETED indicates that CR development completed on
CR branch and the brtype is currently locked but not targeted to an integration build
WORK_COMPLETED followed by the integration branch name indicates that the CR branch is locked and CR is targeted to an integration build
WORK_COMPLETED followed by the integration branch name indicates that the CR branch is locked and CR is targeted to an integration build
WORK_INTEGRATED indicates that CR branch has successfully merged into integration branch
Figure 4-8 Reverse CR Merge State Lifecycle
WORK_STARTED unlock brtype scMergeList
-sub
(VOB Admin)
WORK_TARGETED
<Integration Branch>
WORK_COMPLETED scMergeList -sub (VOB Admin) unlock brtype
WORK_COMPLETED
<Integration Branch> scMergeList -sub (Merge Admin)
WORK_INTEGRATED
<Integration Branch>
The reverse merge state lifecycle figure shows the state transitions when certain actions are executed to undo certain actions. Note that certain actions (e.g. scMergeList -sub) require administrative permissions to undo a state transition. This was to allow the administrators to ensure that no partial merges were actually completed on the integration branch prior to removing any references of the CR to an associated integration branch. In addition, the Technical Authority (TA) will no longer be able to unlock his/her own CR branch type if the CR Merge State is denoted as "WORK_INTEGRATED".
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 42
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
NOTE : By default, the Merge State functionality has been initially disabled for all CQCM CC installations.
Your local VOB administrator must enable this feature prior to its use for your VOBs.
A new kind of CR and branch may be used by development teams to perform frequent incremental integration of their own changes prior to submitting them to an integration build. This Developoment Integration is abbreviated as “ Dev-Integration ” or “ Dev-Int ” and may be performed by creating a corresponding Dev-
Int CR and Dev-Int branch for this particular purpose. This process is as follows:
1. Create and assign a Dev-Int CR
2. Create a corresponding Dev-Int branch (and view) for the Dev-Int CR
3. Configure the Dev-Int branch for appropriate merging
4. Create Dev-Build Baselines on the Dev-Int branch as needed
5. Merge development CR branches and/or temporary (tmp) branches to Dev-Int branch
6. Rebase the Dev-Int branch from the target integration branch
7. Perform the the Dev-Int CR and lock the Dev-Int branch
8. Merge the Dev-Int CR branch to the target integration branch
9. Close the Dev-Int CR
Figure 4-9 Using Dev-Int CRs & Branches for Development Integration depicts a couple of Dev-Int branches each used to collect changes from multiple CR/tmp branches for a particular feature and then merge the result to a formal release integration branch.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 43
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Figure 4-9 Using Dev-Int CRs & Branches for Development Integration
Feature
SR
X
X Rvw
X Rvw
Enhance
SR
CR
<Dev-Int>
Target
CR
<Dev>
Target
Orig_CR
BL
< Dev >
Enhance
SR
BL
< Int >
X Rvw
X Rvw
CR
<Dev-Int>
CR
<Dev>
Target
Orig_CR
BL
< Dev >
Target
BL
< Int >
Feature devintbranch
CR branch
Merge
Merge
X
X
Merge rebase tmp branch
Feature devintbranch tmp branch
CR branch
Merge
X
Merge
Merge tmp branch rebase
X
Release intbranch
Merge
Merge
Notice how each record in the ClearQuest portion of the diagram has a corresponding entity in ClearCase:
• Dev-Integration CRs have a corresponding devint -CR branch in ClearCase
• Development CRs have a corresponding dev -CR branch in ClearCase
• Dev-Build and Int-Build Baseline records have a corresponding ClearCase label
In the above example figure, we have a “New Feature” SR with two child Dev-Int CRs. Then we have two enhancement SRs (presumably against the same Feature-ID as the “New Feature” SR) each with a child Development CR:
• After the first Dev-Int branch has integrated the contents of a tmp branch and a CR branch (and has undergone the requisite inspections), the first Dev-Int branch is rebased from the Release int branch, the result is labeled and baselined, and then it is subsequently merged to the Release int branch.
• Then a new Dev-Int branch is created and it “accumulates” the contents of two more tmp branches and integrates the other Development CR branch, after which it too rebases, labels and baselines, and then merges its result to the same release int branch.
Creating and Assigning a Dev-Int CR
A Dev-Int CR is created much like any other development CR, but with a CR_Usage value of “Dev-
Integration.” The Dev-Int CR’s Target_Type must correspond to a valid parent Baseline-type for a Dev-
Build (hence it cannot be “SCM-Build”) since it must be merged directly to a formal integration branch
(e.g., bld or int branch) or another Dev-Int CR branch (e.g. devint branch)
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 44
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Figure 4-10 Creating and Assigning a Dev-Int CR
CR_Usage = “Dev-Integration”
Creating a Dev-Int CR branch & view
A Dev-Int CR branch is created just like a Development CR branch. By default, Dev-Int CR branches and views will be created as “shared”, to enable Push-model integration.
Configuring a Dev-Int CR branch
Dev-Int CR branches have some noteable differences from other kinds of integration branches:
1. They will not have a release name as part of the branch name. (this is the default for any Development CR branches whose CR has a Target Type of “Dev-Build.”)
2. They need not require the use of scMergeList to enable other branches to merge to the Dev-Int branch
3. They allow in-progress development CR branches and temporary ( tmp ) branches to merge to the Dev-Int branch as often as desired
4. By default, if the corresponding Dev-Int CR has a non-empty Feature-ID other than NFS (Non-
Feature-Specific), then the creation of the Dev-Int branch will automatically create and associate a FeatureID hyperlink for the corresponding Feature-ID, which will have the effect of restricting other CRs merging to the Dev-Int branch to have the same Feature-ID.
The behavior of Dev-Int branches for scMergeList and FeatureID constraints may be reconfigured (modified) after the Dev-Int branch has been created.
Using scMergeList for Dev-Int Branches
By default, scBRMerge will look at the value of the scm-mergelist-on attribute to see whether or not
OK_to_Merge is required in order to merge a CR branch to a Dev-Int branch. This default behavior may be overridden by setting (or clearing) the value of a devint-mergelist-required attribute attached to
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 45
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________ the particular Dev-Int branch. See [1] ClearCase MetaData Standards and Definitions, WSG-PROC-
CM-STD-004 for more details regarding the scm-mergelist-on and devint-mergelist-required attribute types.
Restricting Merges by FeatureID
Both Dev-Int and Integration branches may be constrained to allow merging of CRs only for a specific set of Feature-IDs by creating and/or removing FeatureID hyperlinks to/from the branch:
• If the CR for a to-be-merged CR branch has a Feature-ID that matches that of any of the FeatureID hyperlinks associated with the merge-destination branch, then scBRMerge will allow the CR branch to merge to the target integration or Dev-Int branch.
• If the merge-destination branch has one or more FeatureID hyperlinks, and if the Feature-ID of CR for the to-be-merged CR-branch does not match any of the FeatureID hyperlinks, then scBRMerge will not allow the CR branch to be merged to the target integration or Dev-Int branch.
See ClearCase MetaData Standards and Definitions, WSG-PROC-CM-STD-004 [1] for more details on the FeatureID hyperlink type.
Creating and Using Dev-Build Baselines for a Dev-Int CR
One or more Dev-Build baselines may be created from a Dev-Int CR by the TA or Change-Controller using the Create_Dev_BL action when the CR is Assigned . A Dev-Int CR must have at least one Dev-
Build baseline in order to transition to the Performed state (and all the corresponding Dev-Build baselines for the Dev-Int CR must have a status of Dev-Built , which also means all CRs targeted to those Dev-
Builds must be Closed ).
Figure 4-11 Creating a Dev-Build from a Dev-Int CR
The Field “Originating_CR” captures the Dev Int CR from which this BL was created
Insert screenshot
Once a Dev-Build BL has been created for a Dev-Int CR, all corresponding Dev-Builds created from that
CR may be listed using the Public Query named “Baselines_For_Originating_CR ” which appears under the “ Release_Management ” folder in the “ Common ” queries folder (the fully qualified navigation path of the query is “ Public Queries
D
Common
D
Release_Management
D
Baselines_For_Originating_CR ”).
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 46
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Figure 4-12 Querying all the Dev-Build Baselines for a Dev-Int CR
The Query
“Baselines_For_Originating_CR”
Subsequent operations on this baseline may be taken by the TA or Change-Controller (or Product Baseline
Administrator) by simply editing the Dev-Build baseline record directly. There are typically three things you may want to do with the Dev-Build baseline of a Dev-Int CR:
1. Change the status of the baseline (e.g., to “Dev-Built”)
2. Create a successor for the baseline
3. Change (retarget) the release of the baseline
Retargeting the release of a Dev-Build baseline for a Dev-Int CR will retarget more than just the baseline.
It will also retarget all the corresponding SRs and CRs to the same release. See section Retargeting Long-
Lead Work on a Dev-Int Branch to a Later Release for more details.
Targeting Changes to a Dev-Int branch
Once the Dev-Int CR and a corresponding Dev-Build baseline have been created, other CRs may be targeted to the same Dev-Int branch and build. Such CRs must have a Target_Type of “Dev-Build” and an Actual_Target that corresponds to a Dev-Build for a Dev-Int CR branch.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 47
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
Figure 4-13 A Development CR Targeted to a Dev-Build for a Dev-Int CR
Feature ID may be checked before it may be merged to
Dev-In t
Dev-Build means
CR branch name does not require
Release number
Merging Changes to a Dev-Int branch
Development changes may be made directly on a Dev-Int branch, and they may also be merged to a Dev-
Int branch from a CR branch or from a temporary ( tmp ) branch. When merging from a CR branch to a
Dev-Int branch, the to-be-merged development CR may be in the Assigned or Performed state. Merging an Assigned CR’s branch results in merging potentially in-progress (partial) changes to the Dev-Int branch.
When merging from a Dev-Int branch to another Dev-Int branch, the to-be-merged Dev-Int CR must be in Performed or Closed state. NOTE: If the to-be-merged Dev-Int CR is in the Closed state, the Merge
State of that CR is not updated because it is only intented for rebase purposes.
Merging Completed Changes to a Dev-Int Branch
In order to merge completed changes from a CR branch to a Dev-Int branch, the to-be-merged CR must be Performed , and the to-be-merged branch must be locked. The Target_Type of the to-be-merged CR must be “Dev-Build” and its release (and loadline, if applicable) must match that of the Dev-Int CR.
Merge_Done and Merge_Ready_to_Build hyperlinks are created (as noted in previous sections) as a result of the merge.
Merging In-Progress (Partial) Changes to a Dev-Int Branch
In order to merge in-progress (partial) changes from a CR branch to a Dev-Int branch, the to-be-merged
CR must be Assigned and its release (and loadline, if applicable) must match that of the Dev-Int CR
(the Target_Type need not match when merging in-progress changes). A Partial_Merge_Done hyperlink is created to record the fact that a merge of partial changes was performed.
Merging the Same Change to Both a Dev-Int Branch and to an Integration branch
Sometimes it may be necessary to take a change that is destined for an Integration branch, and to somehow also incorporate that change to a Dev-Int branch, in order to keep the Dev-Int branch “in sync” with ongoing changes and fixes being made. Suppose a particular fix needs to be integrated into a release, and that the Dev-Int branch should also stay “in sync” with the fix.
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 48
Doc Version: 1.06

In this scenario, suppose the corresponding Development CR has a Target_Type of “Int-Build.” Then the Int-
Build targeted Dev-CR may be merged to the Dev-Int branch only while the Dev-CR is still Assigned (Inprogress). It may then be merged to the Int-branch after it is Performed and locked.
Figure 4-14 Merging the same change to both an Int-branch and a Dev-Int branch
Feature
SR
Merging a Fix to a Dev-Int and an Int Branch
ClearQuest
Fault
SR
CR branch
Feature devintbranch
ClearCase
CR
<Dev>
Release intbranch
Merge
CR
<Dev-Int>
Target
BL
< Int >
Merge
Merge
Target
Merge
Orig_CR
BL
< Dev >
BL
< Int >
1.
This merge is done while the CR is still Assigned
2.
This merge is done after the CR has been Performed
Merge States for Changes Targeted/Merged to a Dev-Int Branch
The ability to merge partially completed work to a Dev-Int branch adds new merge-states that corresponds to having partially completed work merged from a branch. This results in not only new merge states but new flow diagrams that are different from those first mentioned in section “Merge States in CQCM CQ/CC Integration” on page 40 . The following two figures depict these alternate merge-states and flows that are possible when
Dev-Int branches are concerned.

Figure 4-15 Forward Merge State Flow for CR Branches Merging to Dev-Int Branches
lock
-obs rmtype
BRTYPE_DELETED WORK_STARTED BRTYPE_OBSOLETED
WORK_PARTIAL_INTEGR
ATED:<Dev-Int_Branch>
WORK_LOCKED_PART_I
NT:<Dev-Int_Branch> scB
RM erg e
(CR
As sign ed) lock scBRMerge
(CR Assigned)
WORK_TARGETED:
<Dev-Int_Branch> scM erg eLis t -a dd
WORK_COMPLETED: scBRMerge
(CR Assigned)
(CR scB
RM form ed)
WORK_COMPLETED:
<Dev-Int_Branch> sc
B
(C
R
R
M
P er er ge fo rm ed
) scBRMerge
(CR Assigned)
WORK_INTEGRATED:
<Dev-Int_Branch>

Figure 4-16 Reverse Merge State Flow for CR Branches Merging to Dev-Int Branches
WORK_INTEGRATED:
<Dev-Int_Branch> unlo ck
WORK_LOCKED_PART_I
NT:<Dev-Int_Branch> scMerge
(VOB A
List -sub dmin)
WORK_PARTIAL_INTEGR
ATED:<Dev-Int_Branch> scMe rgeLis
Adm t -sub in) unl ock
WORK_COMPLETED:
BRTYPE_DELETED rm typ e
WORK_STARTED loc k -o bs loc s k
BRTYPE_OBSOLETED
See ClearCase MetaData Standards and Definitions, WSG-PROC-CM-STD-004 [1] for more details regarding the Partial_Merge_Done , Merge_Done and Merge_Ready_to_Build hyperlink types.

Rebase the Dev-Int Branch from the Target Integration Branch
Before merging the Dev-Int branch to its target integration branch, it is recommended that the Dev-Int branch be rebased from the target integration branch. It may also be desirable (for the purpose of incremental integration) to rebase the Dev-Int branch from the integration branch at frequent intermediate points in time.
Retargeting Long-Lead Work on a Dev-Int Branch to a Later Release
In order to merge to (or rebase from) a target integration branch, the Dev-Int branch’s CR must match the same release as that of the target integration branch. This means the committed release of the Dev-Int branch must be known at that time.
In the case of Long-lead development, it is possible, and even likely, that development work for a given feature had to begin before the feature could be committed to a release. And it may later turn out that feature is committed to a release that is later than the release upon which the feature worked was based.
In such cases, as long as the Dev-Int branch has not yet merged to any other integration branch, the work on the Dev-Int branch may be retargeted to the later release by retargeting the corresponding Dev-Build baseline record for that Dev-Int branch to a later release.
Figure 4-17 Retargeting a Dev-Build to a Later Release
Insert screenshot
Use Button “Check Release Change” to validate that the Release change of
Dev-Build BL with non-empty
Originating CR is allowed
The TA or Change-Controller of the Dev-Int CR (or the BLAdmin for the corresponding Dev-Build BL) may retarget all the work on the Dev-Int branch by editing any one of the Dev-Build Baseline records for the Dev-
Int CR and modifying its “Release” field. The “Check Release Change” button next to the Release field may be used to check if there are any reasons why the retargeting of the Dev-Int CR work should not be permitted.
If it is not permitted, then an “exception” report will be generated indicating which records and/or links and/ or conditions prevent the retargeting from taking place.

If the retargeting is permitted, then all immediate parent SRs of any Dev-Int CRs for the Dev-Build, and all immediate parent SRs of any Dev-CR targeted to any of the Dev-Int CR’s Dev-Build will be retargeted to the subsequent release (and so will any of their child SRs and CRs in the same System).
Figure 4-18 Retargeting the Work on a Dev-Int Branch from a Dev-Build
ClearQuest
Enhance
SR
Retargeting either Dev-BL below will retarget all of the
SRs+CRs+BLs in this diagram
Feature devintbranch
Feature
SR
CR
CR
Target
CR branch
CR
CR branch branch
ClearCase
Merge tmp branch
X
X Rvw
CR
<Dev-Int> Merge
Merge
X
X
Rvw
Rvw
Orig_CR
BL
< Dev >
Merge
Merge
X Rvw
CR
<Dev>
Target
CR branch
CR branch
CR branch
X
Merge
Merge
Merge
X Merge tmp branch tmp branch
Orig_CR
BL
< Dev > X
Merge
Finishing and Merging a Dev-Int CR Branch
Once all changes have been made for a Dev-Int CR and it has been rebased from its target integration branch, then the Dev-Int branch may be locked, all its Dev-Builds should be Dev-Built , and the submit_work action may be taken by the TA to transition the Dev-Int CR to the Performed state.
When the Dev-Int CR is Performed , and the corresponding Dev-Int branch is locked, then the Dev-Int CR branch may be merged to its target integration branch.
After the Dev-Int branch has been merged to its target integration branch, the Dev-Int CR may be closed by its
Coordinator. When a Dev-Int CR is closed against a non-empty Actual_Target, then the latest Dev-Build(s) for the Dev-Int CR will automatically be linked as child BLs of the baseline that is the Actual_Target of the Dev-Int
CR.

Two additional tools are provided to automate the process of propagating or porting a CR change from one CR
(release branch) to another CR (release branch). The propagtion process has been defined to encompass two unique aspects:
• Comparison process - The CR changes should be compared against another labeled baseline version
• Porting process - Execution of the merging process to another propagated CR branch
• crDiffbl - A comparison tool has been provided for identifying discrepancies prior to the actual porting process to an alternate release or loadline. This tool should be used to visually inspect and ensure that only the desirable
CR changes shall be ported to the other release/loadline. This tool displays the differences between the versions of elements modified by a CR against the versions selected by a specified baseline label in ClearCase.
crDiffbl {-cr <CR> | -br <Branch>} {-bl <Baseline Label>} [-nong] [-avobs | -all] [-help] where:
• cr <CR#> - CR with existing checked in changes on an associated CR branch (e.g. 2034)
• br <Branch> - Branch with existing checked in changes in elements
• -bl <Baseline Label> - Valid baseline label that branch CR versions shall be compared against
• -nong - Displays in non-graphical mode (the default is graphical)
• avobs | -all - if avobs is given, all VOBs within the CLEARCASE_AVOBS env variable is searched. If -all option is given, only the elements within the current VOB is considered. If -avobs or -avobs is not given, then
-avobs is defaulted.
• -help - displays help with usage
The crDiffbl tool initially executes a ’cleartool find’ to capture all associated file and directory elements within the VOB(s) with the specified CR branch instances. This element list is displayed to the user and prompts the user to select an element or cancel out. If the user selects an element from the displayed list, the ClearCase diff tool is executed to display the differences between the latest checkedin version of the element vs. the element version selected by the specified baseline label. If the element is not labeled with the specified baseline label, then the / main/0 version is used for comparison. Once the ’cleartool diff’ window is closed, the element list is then prompted to the user once again. The user is prompted to select each element in the list until the user either selects the Abort button or until all elements have been reviewed using the ’cleartool diff’ tool.
• portCR - The second tool provided automates the porting process by combining the ClearCase steps required for this process. This automatically creates a new CR view/branch and executes the merge for all the changes on an existing CR branch to the newly created CR view/branch.
portCR {-f.cr <Source CR>} {-t.cr <Target CR>} [-b.aseline <Baseline Label>] [-h.elp] where:
• -f.cr <Source CR> - Source CR with existing changes on an associated CR branch
• -t.cr <Target CR> - Target (Destination) CR that is assigned to current user
• -b.aseline|-bl <Baseline Label> - Valid baseline label that target CR view shall be based upon
• -h.elp - displays help with usage

The portCR tool validates that the target CR specified must be assigned to the current user prior to continuing. It also validates that the source CR has a valid CR branch type in the ClearCase VOB as well as validates that the baseline label specified is a valid label type in the VOB. To ensure that all required elements are merged, the
CLEARCASE_AVOBS environment variable must be set prior to its execution.
The portCR tool then continues by executing the mkview tool to create a new view/branch type for the given target
CR. If the view already exists, then the portCR script continues by executing the final step of merging. For merging, the scBRMerge tool with the -delta option is then called to merge the latest checkedin changes on the source CR branch to the newly created target CR branch/view.
ClearCase uses two primary mechanisms for access restrictions to a ClearCase VOB:
• Unix group and owner permissions
• ClearCase Cleartool Lock commands - cleartool lock, cleartool protect
By default, ClearCase maintains the original permissions and ownership of the file or directory as it was initially checked into the VOB (mkelem). ClearCase also considers the umask of the user when creating new elements in a ClearCase VOB. For example, if a ClearCase developer has a umask of 077, any element created by this user will not be readable or writeable by anyone else.
The mkelem post-trigger attempts to create a consistent ownership and permissions setting for all elements in the
VOB. After a successful element creation, this trigger executes a 'cleartool protect' to ensure that the element is:
1) owned by the VOB Admin account (configurable in config file)
2) group set to single group account (configurable in config file)
3) element is readable by owner, group, and other
4) element is writeable by owner or group
Unix groups provide one mechanism of limiting access at the VOB level. ClearCase locks (cleartool lock) provide the another mechanism of locking any ClearCase object, where an object may be:
• a type object (branch type, label type, attribute type, element type, etc.)
• locking a type object locks all instances of the type in the VOB
• e.g. locking a branch type locks all branch instances in the VOB element
• locking an element prevents all write operations to the element except for excluded users VOB
• locking a VOB prevents all write operations to all elements and metadata in the VOB branch
• an individual branch instance in an element may be also locked.
To "lock down" a directory structure or portion of a tree, you may use something like the following but you must add any users who will act as integrators or who must label elements or you will not be able to perform a build:
$ find . -exec cleartool lock -nusers "mmccadmn" {} \; or
$ find . -exec cleartool protect -chmod 755 {} \;
Either method may be used to restrict access to all files and directory elements to only the VOB administrator, but this step assumes all code has already been checked into the VOB (mkelem) prior to applying the lock or changing protections of the elements.

INTERNAL
___________________________________________________________________________________________________
The following examples uses the Sandbox VOB which may be accessed from the csdbld02 server. You can use the sandbox to get the feel of the CQCM system. The sandbox is a fully functioning CM environment where you can "play" with the CQ and CC functionality.
This scenario follows the flow of UNIX commands necessary for checking in a code fragment home.c
, checking it out and making changes then checking it back in order to perform a merge to an integration branch. The CR work must be completed before the state of the CR can be set to performed. The process is similiar for Windows users. Refer to ClearCase Concepts and Reference Guide, COM-TOOL-CM-REF-
001 [6] for more specific usage for the Windows operating system and on how to use the Windows version of ClearCase to perform the same type of tasks.
Note that you must be on a machine for the appropriate ClearCase region that has access to the VOB. In the following example we are using the machine name shown below.
$ rlogin csdbld02
$ . scstart sbox
TIP: for ksh, tcsh, and csh users ksh users
. /usr/test/scmtool/prod/cmbp/bin/scstart <Product Family Name e.g. sdu> csh users
% source /usr/test/scmtool/prod/cmbp/bin/scstart.csh
List of valid Product Family Names: sdu cp train sproc bpp test cca cots isb scm shsrv sst tools doc metrics scmtools tcsh users source /usr/test/scmtool/prod/cmbp/bin/scstart.tcsh <Product Family Name e.g sdu>
1. Run the mkview command
$ mkview -cr 529 -b SBOX_R16.3_REL-02
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 56
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________ screen output ....
Created branch-types: brtype:r16.3_dev-529@/usr/vob/sc/sbox
View Storage location will be defaulted to host:csdview01 gpath:/usr/prod/ sc_view11/cmbp
Created view smusini1_r16.3_dev-529
view storage is /usr/prod/sc_view11/cmbp/smusini1_r16.3_dev-529.vws
########## Config-spec for view smusini1_r16.3_dev-529 ##########
#----------------------------------------------------------------------#
# CMBlueprint - ClearCase View Config Spec
# Development rules: element * CHECKEDOUT element * .../r16.3_dev-529/LATEST mkbranch r16.3_dev-529 element * SBOX_R16.3_REL-02 element * /main/LATEST
#----------------------------------------------------------------------#
2. Set to newly created view
$ cleartool setview smusini1_r16.3_dev-529
3. Checkout the file to do some code changes.
$ cleartool co home.c
------------------------------------------------------------------------
Created branch "r16.3_dev-529" from "home.c" version "/main/2".
Checked out "home.c" from version "/main/r16.3_dev-529/0".
-----------------------------------------------------------------------
At this point a trigger informs ClearQuest that a new branch has been created to work on a CR and an email is sent to the developer. Here you can take a code fragment and do a change on it using your favorite editor.
4. After your work is done you check the file back in.
$ cleartool ci home.c
------------------------------------------------------------------------
Checked in "home.c" version "/main/r16.3_dev-529/1".
---------------------------------------------------------------------------
5. Make integration view
$ mkview -tag sbox_r16.3_int-03 -b SBOX_R16.3_REL-02
------------------------------------------------------------------------
Created branch-types: sbox_r16.3_int-03@/usr/vob/sc/sbox
Created view sbox_r16.3_int-03
view storage is /usr/prod/sc_view11/cmbp/sbox_r16.3_int-03.vws
########## Config-spec for view sbox_r16.3_int-03 ##########
#----------------------------------------------------------------------#
# CMBlueprint - ClearCase View Config Spec
#
# Development rules: element * CHECKEDOUT element * .../sbox_r16.3_int-03/LATEST mkbranch sbox_r16.3_int-03 element * SBOX_R16.3_REL-02 element * /main/LATEST
6. Set to the integration view
$ cleartool setview sbox_r16.3_int-03
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 57
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
7. Lock the CR branch - you must do a manual lock.
$ cleartool lock -rep brtype:r16.3_dev-529
------------------------------------------------------------------------
Locked branch type "r16.3_dev-529".
------------------------------------------------------------------------
8. Can only merge branches that have permission to merge into an int branch
$ scBRMerge -f r16.3_dev-529
9. Give permission to merge - this is done by a dedicated builder depending on the push/pull model that your group uses.
$ scMergeList -add -f r16.3_dev-529
... [text removed]...-----------------------------------------------r16.3_dev-529 is now 'OK to merge (Ok_to_merge)' to sbox_r16.3_int-03
---------------------------------------------------------------------------
10. Merge the r16.3_dev-529 - example of the merge output upon successful merge
------------------------------------------------------------------------
$ scBRMerge -f r16.3_dev-529
********************************
<<< file 1: /usr/vob/sc/sbox/home.c@@/main/2
>>> file 2: /usr/vob/sc/sbox/home.c@@/main/r16.3_dev-529/1
>>> file 3: /usr/vob/sc/sbox/home.c
********************************
Moved contributor "/usr/vob/sc/sbox/home.c" to "/usr/vob/sc/sbox/home.c.contrib".
Output of merge is in "/usr/vob/sc/sbox/home.c".
Recorded merge of "/usr/vob/sc/sbox/home.c".
Checked in "/usr/vob/sc/sbox/home.c" version "/main/sbox_r16.3_int-03/1".
**** All merges were SUCCESSFUL ****
-------------------------------------------------------------------------
11.
Report on merges
$ mergestat
********************************************************************************
BRANCH: sbox_r16.3_int-03
VIEW: sbox_r16.3_int-03
********************************************************************************
Merged Merge Merge
Branch Begun Done
------------------------------------- --------- --------------
r16.3_dev-529 yes yes
********************************************************************************
Merges completed/Total Merges Required = 1/1
Checking to see if any elements are checked out from branch "sbox_r16.3_int-03"
This scenario follows the flow of UNIX commands necessary for the development and integration of a source file using the Agile development process. This example shows the workflow of a “long-lead” Dev-
Int branch type and view from creation through eventual merge into an integration branch. The CR work must be completed before the state of the Dev-Int CR can be set to Performed , but the hybrid nature of the
Dev-Int CR branch allows other various branch types to be iteratively merged and tracked on the Dev-Int
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 58
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________ branch. In addition, this example will attempt to illustrate the flexibility of Dev-Int branches in also allowing
Assigned CRs and tmp branches the ability to merge to a Dev-Int branch/view.
Assumptions: CR 142190: CR Usage = Dev-Integration
Target Type = Int-Build
Feature ID = 9140A
Predicted Release = Release-17.0
CR State = Assigned
CR 142191: CR Usage = Development
Target Type = Dev-Build
Feature ID = 9140A
Predicted Release = Release-17.0
CR State = Assigned
1. Run the mkview command for the Dev-Build targeted CR
$ mkview -cr 142191 -b SCMTEST_R17.0_REL-00 screen output ....
Created branch-types: brtype:dev-142191@/usr/vob/sc/scmtest
Created view rlee1_dev-142191
view storage is /usr/prod/sc_view13/cmbp/rlee1_dev-142191.vws
########## Config-spec for view rlee1_dev-142191 ##########
#----------------------------------------------------------------------#
# CMBlueprint - ClearCase View Config Spec
# Development rules:
# element * CHECKEDOUT element * .../dev-142191/LATEST element .../lost+found -none mkbranch dev-142191 element * SCMTEST_R17.0_REL-00 element * /main/LATEST
#----------------------------------------------------------------------#
Successfully created view rlee1_dev-142191
view storage is /usr/prod/sc_view13/cmbp/rlee1_dev-142191.vws
2. Run the mkview command for the Dev-Int CR
$ mkview -cr 142190 -b SCMTEST_R17.0_REL-00 screen output ....
Created branch-types: brtype:devint-142190@/usr/vob/sc/scmtest
Created view devint-142190
view storage is /usr/prod/sc_view13/cmbp/devint-142190.vws
########## Config-spec for view devint-142190 ##########
#----------------------------------------------------------------------#
# CMBlueprint - ClearCase View Config Spec
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 59
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
# Development rules:
# element * CHECKEDOUT element * .../devint-142190/LATEST element .../lost+found -none mkbranch devint-142190 element * SCMTEST_R17.0_REL-00 element * /main/LATEST
#----------------------------------------------------------------------#
Successfully created view devint-142190
view storage is /usr/prod/sc_view13/cmbp/devint-142190.vws
3. Note and modify (if necessary) current default customizable attributes of Dev-Int CR branch type
$ cleartool describe brtype:devint-142190
-----------------------------------------------------------------------branch type "devint-142190"
created 20-Dec-05.23:35:37 by Raymond R. Lee {RLEE1} (rlee1.CID@csdbld04)
master replica: scmtest@/usr/vob/sc/scmtest
request for mastership: allowed for all instances
owner: rlee1
group: CID
scope: global
constraint: one version per element
Attributes:
OriginatingCR = "MOTSB00142190"
devint-merge-list-required = 1
Hyperlinks:
FeatureID -> "9140A"
------------------------------------------------------------------------
Note that the default value of the devint-merge-list-required attribute value = 1. This indicates that users will not be able to merge to this Dev-Int branch without scMergeList permission. To relax the scMergeList restriction on this Dev-Int branch, the Dev-Int branch owner may either set the value of this attribute to 0 or remove the attribute from the Dev-Int branch type:
$ cleartool rmattr devint-merge-list-required brtype:devint-142190
Removed attribute "devint-merge-list-required" from "devint-142190".
Also of note is the FeatureID hyperlink automatically attached to the Dev-Int CR branch type. This
FeatureID hyperlink indicates that the Dev-Int branch is feature-constrained and shall allow only merges from CRs of the same Feature-ID. For Dev-Int CRs where the Feature-ID is not NULL nor NFS, the initial
FeatureID hyperlink is automatically attached. A Dev-Int branch type with NO FeatureID hyperlinks indicate that the Dev-Int branch is NOT feature-constrained. Additional FeatureID hyperlinks may also be added to allow merges from CRs for multiple features.
$ cleartool mkhlink -ttext "9133" FeatureID brtype:devint-142190
Created hyperlink "FeatureID@6078@/usr/vob/sc/scmtest".
4. Set to newly created Dev-Int CR view
$ cleartool setview devint-142190
5. Direct checkouts on Dev-Int CR branches are permitted
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 60
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
$ cleartool co home.c
-----------------------------------------------------------------------
Created branch "devint-142190" from "home.c" version "/main/2".
Checked out "home.c" from version "/main/devint-142190/0".
-----------------------------------------------------------------------
$ cleartool unco -rm home.c
------------------------------------------------------------------------
Checkout cancelled for "home.c".
------------------------------------------------------------------------
6. Merge Assigned CR branch into Dev-Int view
$ scBRMerge -f dev-142191 screen output of successful merge NOT shown here...
7. Report on In-Progress ( Assigned ) CR merge
$ mergestat
**************************************************************************
BRANCH: devint-142190
VIEW: devint-142190
**************************************************************************
Merged Merge Time Partial Merge
Branch Begun Merge Done
----------------------- --------- ---------------------------- ------------ -----------
dev-142191 yes 21-Dec-05.00:34:56 yes no
**************************************************************************
Merges completed/Total Merges Required = 0/1
8. Merge Assigned CR branch to Dev-Int view again and Report on merges
$ scBRMerge -f dev-142191 screen output of successful merge NOT shown here...
$ mergestat
**************************************************************************
BRANCH: devint-142190
VIEW: devint-142190
**************************************************************************
Merged Merge Time Partial Merge
Branch Begun Merge Done
----------------------- --------- ---------------------------- ------------ -----------
dev-142191 yes 21-Dec-05.00:34:56 yes no
yes 21-Dec-05.00:56:57 yes no
**************************************************************************
Merges completed/Total Merges Required = 0/1
9. Lock Dev-CR branch type and Perform CR in CQ
$ cleartool lock -rep brtype:dev-142191
Locked branch type "dev-142191".
10. Merge Performed CR and Report on merges to Dev-Int
$ scBRMerge -f dev-142191
**** No merges were found to be necessary. ****
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 61
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
$ mergestat
**************************************************************************
BRANCH: devint-142190
VIEW: devint-142190
**************************************************************************
Merged Merge Time Partial Merge
Branch Begun Merge Done
----------------------- --------- ---------------------------- ------------ -----------
dev-142191 yes 21-Dec-05.00:34:56 yes yes
yes 21-Dec-05.00:56:57 yes yes
**************************************************************************
Merges completed/Total Merges Required = 1/1
11. Merges of tmp branches are also permitted
$ scBRMerge -f rlee1_tmp-agile screen output of successful merge NOT shown here...
$ mergestat
**************************************************************************
BRANCH: devint-142190
VIEW: devint-142190
**************************************************************************
Merged Merge Time Partial Merge
Branch Begun Merge Done
----------------------- --------- ---------------------------- ------------ -----------
dev-142191 yes 21-Dec-05.00:34:56 yes yes
yes 21-Dec-05.00:56:57 yes yes rlee1_tmp-agile yes 21-Dec-05.01:19:01 yes no
**************************************************************************
Merges completed/Total Merges Required = 1/2
NOTE: Since there is currently no mechanism for indicating that the changes on a tmp branch has been completed, tmp branches will always be marked as “no” in the Merge Done column of the mergestat report.
12. Create integration view for merging Dev-Int CR
$ mkview -tag scmtest_r17.0_int-03 -b SCMTEST_R17.0_REL-02
------------------------------------------------------------------------
Created branch-types: scmtest_r17.0_int-03@/usr/vob/sc/scmtest
Created view scmtest_r17.0_int-03
view storage is /usr/prod/sc_view11/cmbp/scmtest_r17.0_int-03.vws
########## Config-spec for view scmtest_r17.0_int-03 ##########
#----------------------------------------------------------------------#
# CQCM - ClearCase View Config Spec
#
# Development rules: element * CHECKEDOUT element * .../scmtest_r17.0_int-03/LATEST element .../lost+found -none mkbranch scmtest_r17.0_int-03 element * SCMTEST_R17.0_REL-02 element * /main/LATEST
13. Set to the integration view
$ cleartool setview scmtest_r17.0_int-03
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 62
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
14. Lock the CR branch - you must do a manual lock.
$ cleartool lock -rep brtype:devint-142190
------------------------------------------------------------------------
Locked branch type "devint-142190".
------------------------------------------------------------------------
15. Perform (submit_work action) CR in CQ
16. Can only merge branches that have permission to merge into an int branch
$ scBRMerge -f devint-142190
17. Give permission to merge - this is done by a dedicated builder depending on the push/pull model that your group uses.
$ scMergeList -add -f devint-142190
... [text removed]...
-----------------------------------------------------------------------devint-142190 is now 'OK to merge (Ok_to_merge)' to scmtest_r17.0_int-03
------------------------------------------------------------------------
18. Merge the devint-142190
------------------------------------------------------------------------
$ scBRMerge -f devint-142190 screen output of successful merge NOT shown here...
**** All merges were SUCCESSFUL ****
-------------------------------------------------------------------------
19. Report on merges
$ mergestat
********************************************************************************
BRANCH: scmtest_r17.0_int-03
VIEW: scmtest_r17.0_int-03
********************************************************************************
Merged Merge Merge
Branch Begun Done
------------------------------------- --------- --------------
devint-142190 yes yes
********************************************************************************
Merges completed/Total Merges Required = 1/1
Checking to see if any elements are checked out from branch "scmtest_r17.0_int-03"
This is another example similar to Example 1 using the Sandbox VOB. In the exercise CR
MOTSB00000396 has been assigned to Ray Lee. Each numbered step is a command.
1. Run mkview
$ mkview -cr 396 -b SBOX_PRE16.3_REL-10
------------------------------------------------------------------------
Created branch-types: r16.3_dev-396@/usr/vob/sc/sbox
Created view rlee1_r16.3_dev-396
view storage is /usr/prod/sc_view11/cmbp/rlee1_r16.3_dev-396.vws
########## Config-spec for view rlee1_r16.3_dev-396 ##########
#----------------------------------------------------------------------#
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 63
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
# CQCM - ClearCase View Config Spec
#
# Development rules: element * CHECKEDOUT element * .../r16.3_dev-396/LATEST mkbranch r16.3_dev-396 element * SBOX_PRE16.3_REL-10 element * /main/LATEST
---------------------------------------------------------------------------
2. Set to view
$ cleartool setview rlee1_r16.3_dev-396
3. Checkout the file you wish to modify
$ cleartool co home.c
---------------------------------------------------------------------------
Checked out "home.c" from version "/main/r16.3_dev-396/1".
We checked out the file we wish to edit and make some trivial changes for the sake of the example.
----------------------------------------------------------------------
4. Check in the file
$ cleartool ci home.c
-----------------------------------------------------------------------
Checked in "home.c" version "/main/r16.3_dev-396/1".
-----------------------------------------------------------------------
5. Lock the branch.
$ cleartool lock -rep brtype:r16.3_dev-396
-------------------------------------------------------------------------
Locked branch type "r16.3_dev-396".
-----------------------------------------------------------------------
We lock the branch so that no other changes can be made on that branch.
6. Exit CR view
$ exit
We exit view shell and run mkview from the command line.
7. Run the mkview command
$ mkview -tag sbox_pre16.3_int-11 -b SBOX_PRE16.3_REL-10
-----------------------------------------------------------------------
Created branch-types: sbox_pre16.3_int-11@/usr/vob/sc/sbox
Created view sbox_pre16.3_int-11
view storage is /usr/prod/sc_view11/cmbp/sbox_pre16.3_int-11.vws
########## Config-spec for view sbox_pre16.3_int-11 ##########
#----------------------------------------------------------------------#
# CQCM - ClearCase View Config Spec
#
# Development rules: element * CHECKEDOUT element * .../sbox_pre16.3_int-11/LATEST mkbranch sbox_pre16.3_int-11 element * SBOX_PRE16.3_REL-10 element * /main/LATEST
#----------------------------------------------------------------------#
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 64
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
$ cleartool setview sbox_pre16.3_int-11
$ scMergeList -add -b SBOX_PRE16.3_INT-11 r16.3_dev-396 is now 'OK to merge (Ok_to_merge)' to sbox_pre16.3_int-11
-----------------------------------------------------------------------
8. Run the mergestat command
$ mergestat
Now we run the mergestat command.
Branch scBRMerge Ready to build
------------------------------------- --------- --------------
r16.3_dev-396 no no
9. Now run the scBRMerge command to merge CR 396 into integration view/branch
$ scBRMerge -f r16.3_dev-396
Needs Merge "/usr/vob/sc/sbox/home.c" [(automatic) to /main/6 from /main/ r16.3_dev-396/1 (base also /main/6)]
Created branch "sbox_pre16.3_int-11" from "/usr/vob/sc/sbox/home.c" version "/ main/6".
Checked out "/usr/vob/sc/sbox/home.c" from version "/main/sbox_pre16.3_int-11/0".
Trivial merge: "/usr/vob/sc/sbox/home.c" is same as base "/usr/vob/sc/sbox/ home.c@@/main/6".
Copying "/usr/vob/sc/sbox/home.c@@/main/r16.3_dev-396/1" to output file.
Moved contributor "/usr/vob/sc/sbox/home.c" to "/usr/vob/sc/sbox/home.c.contrib".
Output of merge is in "/usr/vob/sc/sbox/home.c".
Recorded merge of "/usr/vob/sc/sbox/home.c".
Checked in "/usr/vob/sc/sbox/home.c" version "/main/sbox_pre16.3_int-11/1".
**** All merges were SUCCESSFUL ****
-----------------------------------------------------------------------
10. Run mergestat
$ mergestat
********************************************************************************
BRANCH: scmtools-cmbp_pre3.1_int-3.0-01
VIEW: scmtools-cmbp_pre3.1_int-3.0-01
********************************************************************************
Merged Merge Merge
Branch Begun Done
------------------------------------- --------- --------------
r16.3_dev-396 yes yes
********************************************************************************
Merges completed/Total Merges Required = 1/1
Example 1 : Alternate mainline view using DevProject files for including customized rules
$ mkview -cr 277 -b SCMTEST_R16.1_REL-00
Created view rlee1_r16.1_dev-277
view storage is /usr/prod/sc_view18/cmbp/rlee1_r16.1_dev-277.vws
########## Config-spec for view rlee1_r16.1_dev-277 ##########
#----------------------------------------------------------------------#
# CQCM - ClearCase View Config Spec
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 65
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
# (Using DevProject 'SCMTEST_PRE16.3_REL-01' located at:
# /usr/prod/vobstore203/cmbp/scmtest/cm-policy/bin/../config/CDMA_projects/ scmtest_r16.1_rel-01.prj)
# Development rules:
#
# DEVPROJECT RULES BEGIN
# element * LABEL1 element * CHECKEDOUT element * .../r16.1_dev-277/LATEST mkbranch r16.1_dev-277 element * SCMTEST_R16.1_REL-00
# DEVPROJECT RULES MIDDLE
# element * LABEL2 element * .../r16.1-main/0 element * /main/R16.1 element * /main/0 end mkbranch r16.1_dev-277
# DEVPROJECT RULES END
# element * LABEL3
#----------------------------------------------------------------------#
Example 2 : Alternate mainline view without DevProject files
$ mkview -cr 277 -b SCMTEST_R16.1_REL-01
Do you want to associate the view with a DevProject? (y/n)n
Created view rlee1_r16.1_dev-277
view storage is /usr/prod/sc_view18/cmbp/rlee1_r16.1_dev-277.vws
########## Config-spec for view rlee1_r16.1_dev-277 ##########
#----------------------------------------------------------------------#
# CQCM - ClearCase View Config Spec
# Development rules:
# element * CHECKEDOUT element * .../r16.1_dev-277/LATEST mkbranch r16.1_dev-277 element * SCMTEST_R16.1_REL-01 element * .../r16.1-main/0 element * /main/R16.1 element * /main/0 end mkbranch r16.1_dev-277
#----------------------------------------------------------------------#
Example 3 : CR view using bldlabels functionality to automatically determine baseline
$ mkview -cr 247
Created view rlee1_r16.3_dev-247
view storage is /usr/prod/sc_view18/cmbp/rlee1_r16.3_dev-247.vws
########## Config-spec for view rlee1_r16.3_dev-247 ##########
#----------------------------------------------------------------------#
# CQCM - ClearCase View Config Spec
# Development rules:
# element * CHECKEDOUT element * .../r16.3_dev-247/LATEST mkbranch r16.3_dev-247 element * SCMTEST_PRE16.3_REL-03 element * /main/LATEST
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 66
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________
#----------------------------------------------------------------------#
Example 4 : CR view using bldlabels and component functionality to automatically determine baseline for a given component value
$ mkview -cr 248 -comp SCMTEST2
Created view rlee1_r16.3_dev-247
view storage is /usr/prod/sc_view18/cmbp/rlee1_r16.3_dev-247.vws
########## Config-spec for view rlee1_r16.3_dev-247 ##########
#----------------------------------------------------------------------#
# CQCM - ClearCase View Config Spec
# Development rules:
# element * CHECKEDOUT element * .../r16.3_dev-248/LATEST mkbranch r16.3_dev-248 element * SCMTEST2_R16.3_REL-02 element * /main/LATEST
#----------------------------------------------------------------------#
Example 5 : Sandbox (Tmp) View
$ mkview -tag rlee1_tmp-mytest -b SCMTEST_PRE16.3_REL-02
Do you want to associate the view with a DevProject? (y/n)n
Created view rlee1_tmp-mytest
view storage is /usr/prod/sc_view18/cmbp/rlee1_tmp-mytest.vws
########## Config-spec for view rlee1_tmp-mytest ##########
#----------------------------------------------------------------------#
# CQCM - ClearCase View Config Spec
# Development rules:
# element * CHECKEDOUT element * .../rlee1_tmp-mytest/LATEST mkbranch rlee1_tmp-mytest element * SCMTEST_PRE16.3_REL-02 element * /main/LATEST
#----------------------------------------------------------------------#
Example 6: Dev-Int View (ClearQuest CR_Usage=Dev-Integration)
$ mkview -cr 5678 -b SCMTEST_R16.3_REL-22
Created branch-types: devint-5678@/usr/vob/sc/scmtest
Created view devint-5678
view storage is /usr/prod/sc_view18/cmbp/devint-5678.vws
########## Config-spec for view devint-5678 ##########
#----------------------------------------------------------------------#
# CQCM - ClearCase View Config Spec
# Development rules:
# element * CHECKEDOUT element * .../devint-5678/LATEST element .../lost+found -none mkbranch devint-5678 element * SCMTEST_R16.3_REL-22
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 67
Doc Version: 1.06

INTERNAL
___________________________________________________________________________________________________ element * /main/LATEST
#----------------------------------------------------------------------#
Example 7: Dev-Int View (ClearQuest CR_Usage=Dev-Integration)
$ mkview -tag feat-28351_devint-5678 -b SCMTEST_R16.3_REL-22
Created branch-types: feat-28351_devint-5678@/usr/vob/sc/scmtest
Created view feat-28351_devint-5678
view storage is /usr/prod/sc_view18/cmbp/feat-28351_devint-5678.vws
########## Config-spec for view feat-28351_devint-5678 ##########
#----------------------------------------------------------------------#
# CQCM - ClearCase View Config Spec
# Development rules:
# element * CHECKEDOUT element * .../feat-28351_devint-5678/LATEST element .../lost+found -none mkbranch feat-28351_devint-5678 element * SCMTEST_R16.3_REL-22 element * /main/LATEST
#----------------------------------------------------------------------#
Example 8: Dev-CR View Targeted to Dev-Int (ClearQuest CR Target_Type=Dev-Build)
$ mkview -cr 6789 -b SCMTEST_R16.3_REL-22
Created branch-types: dev-6789@/usr/vob/sc/scmtest
Created view rlee1_dev-6789
view storage is /usr/prod/sc_view18/cmbp/dev-6789.vws
########## Config-spec for view rlee1_dev-6789 ##########
#----------------------------------------------------------------------#
# CQCM - ClearCase View Config Spec
# Development rules:
# element * CHECKEDOUT element * .../dev-6789/LATEST element .../lost+found -none mkbranch dev-6789 element * SCMTEST_R16.3_REL-22 element * /main/LATEST
#----------------------------------------------------------------------#
Example 9: mkview with option to display list of currently “My Assigned CRs”
$ mkview -cr “?”
The following are CR(s) assigned to you:
MOTSB00184955 Tracy's test SR
MOTSB00183650 loadline test
MOTSB00167087 Tracy's test SR
____________________________________________________________________________________________________
Doc ID: COM-TOOL-CM-UG-003 68
Doc Version: 1.06