ClearCase Basics

Course Goals Introduce SCM Demonstrate typical developer workflow Identify other ClearCase tasks Demonstrate parallel development

What this course does not cover? Complete implementation of software configuration management Complete features of ClearCase tool Administrator’s tasks ClearCase MultiSite

Software Configuration Management (SCM) SCM “ SCM is about managing change to software” Brian White , Software Configuration Management Strategies and Rational ClearCase (2000)

What is SCM? SCM is a software engineering discipline comprising the tools and techniques (processes or methodology) that a company uses to manage changes to its software assets. SCM answers who, what, when and why

Why SCM? Multiple individuals work on software that is changing. More than one version of the software has to be supported. Decrease time to market Control Cost

Why SCM? (Cont) A successful SCM effort ensures : Safety Stability Control Auditability Reporducibility Traceability Scalability

SCM Tools ClearCase - Rational Software Visual Source Safe - Microsoft PVCS - Merant (previously Intersolv) Continnus - Telelogic (acquired Continnus)

Introduction to Rational ClearCase Family

IBM Rational ClearCase family Provides software asset management through features such as version control, baseline management, and build and release management Consists of three key products: IBM Rational ClearCase LT IBM Rational ClearCase IBM Rational ClearCase MultiSite

ClearCase family – At a glance

Capabilities Manage change across the software life cycle—from design to code to test Simplify development with activity-based change management Improve team collaboration with out-of-the-box process automation and workflow management Enable parallel development

Capabilities (cont) Support asset-based development for software reuse Speed application delivery with advanced build and release management Provide real-time project status Support direct access to assets and changes from within leading integrated development environments (IDEs)

Capabilities (cont) Improve the ability to meet regulatory requirements with audit support Scale from small workgroups to geographically distributed enterprises

ClearCase implements SCM Version control Version all types of files and directories Build Management Ensure the integrity of all software elements Accurately reproduce every release Trace and reproduce builds Workspace management Work in parallel with other developers Process control Record and report actions, history, and milestones Customize process

ClearCase Roles ClearCase developer Set up workspace Make changes Integrate changes Update workspace ClearCase integrator Create integration workspace Create Baseline Build components

ClearCase Roles (cont) ClearCase Configuration manager Write CM plan Design development environment Establish CM policies Assign and schedule work Monitor project status

ClearCase Roles (cont) ClearCase administrator Setup hardware environment Implement development environment Maintain hardware and development environments

Typical Developer Workflow Set up workspace Create a view Start a view Mount a VOB Work on files Configuration workspace Checkout files Edit files Check in files Merge work Merge work to integration area Merge from integration area

Typical Workflow: Setting Up Your Workspace Set up workspace Create a view Start a view Mount a VOB

What is a Versioned Object Base (VOB)? A permanent, read-only data repository that: Stores files, directories, and metadata Stores version-controlled data Displays its contents as files in a file system Stores anything that can be represented as file or directory Can be replicated in two or more sites VOB

Projects and VOBs A project can span more than one VOB Multiple projects can share common VOBs Project 1 Project 2 VOB A VOB B VOB C

What is an Element? A file or directory, under source control, stored in a ClearCase VOB Can be any object that can be stored in a native file system, including Source files Directories Binary files Object libraries Documents

What is a Version? An element consists of a set of versions, organized into a version tree Each version represents one version of a file under source control Versions are displayed in a workspace or view Versions of element hello.c 0 1 2 3

What is a View? A ClearCase mechanism that allows users access to versions of elements in VOBs An isolated workspace for a user or a group Enables users to work in parallel VOB Hello.c Util.c Hello.c v.3 util.c v.2 0 1 2 3 0 1 2 3 View

What is a Configuration Specification? For each view, a set of ordered rules used to select at most one version of each element Determine which versions of an element are visible in the new view VOB hello.c Util.c hello.c v.3 util.c v.2 Configuration Specification VIEW 0 1 2 3 0 1 2 3

Types of Views Dynamic views use the ClearCase multi version file system (MVFS) to provide immediate, transparent access to files and directories stored in VOBs Connected to shared storage Work on virtual copy of elements in the VOB (MVFS) Dynamic – changes as new work is shared Always up-to-date Provides build auditing Snapshot views Copy files and directories from VOBs to a directory on your computer Can work disconnected from shared storage Work on local copy of elements in the VOB (native file system) Static – user controls when work is shared Must be updated manually Provides optimal build performance

Which Type of View Should I Use? Dynamic You want to access elements in repositories without copying them into your computer You want to view to reflect changes made by other team members at all times Your project uses build auditing Snapshot You are using Win 9X, Win ME, or ClearCase LT, which do not support dynamic views You want to work disconnected from the network You do not need build avoidance

Structure of a Dynamic View VOB 0 1 2 Hello.c Util.c hello.c Read/write util.c Read-only Virtual File System View Storage hello.c Check out Configuration Specification 0 1 2 3

Structure of a Snapshot View VOB 0 1 2 hello.c util.c hello.c Read/write copy util.c Read-only copy Local File System Configuration Specification Check out 0 1 2 3

Shortcut Pane Folder Pane Details Pane Information Pane Intro to ClearCase Explorer

Creating a Dynamic View 1 Launch the View Creation Wizard Toolbox tab 2 Select Dynamic View

Creating a Dynamic View (Cont.) 3 Choose a view name (or view-tag) 4 Select a drive letter to which you want to connect the new view, or you can select {none} and work directly on the MVFS(M:) drive 5 Click Advanced Options 6 Accept the default or specify the location of the view storage directory 7 Click on Finish

Starting a View 1 Click Start View 2 Select the view you want to start, and then click OK Each view has a unique tag name When you create a dynamic view, it starts automatically

Mounting a VOB for Dynamic Views The mount command activates a VOB for use on the local workstation You access a VOB through its unique tag name

Typical Workflow: Work on Files Work on Files Configure workspace Check out files Edit files Check in files

Checkout / Checkin Model When a file is under source control, you check it out to work on it A file is checked out to a view and a modifiable copy is available to work on A placeholder is created in the version tree as the potential successor version When you check in the file, a new version is added to the element version tree 2 3 R Placeholder

View before and after Checking out VOB 0 1 2 Hello.c Util.c hello.c Read/write util.c Read-only View display View Storage hello.c Check out Configuration Specification VOB 0 1 2 Hello.c Util.c hello.c Read-only util.c Read-only Configuration Specification View display Before checking out After checking out 0 1 2 3 0 1 2 3

Types of Checkout Reserved checkout: Default checkout Has exclusive rights to next place on version tree No checkins can be made on the same branch until the checkout is resolved Only allowed if no other reserved checkouts exist for the branch Unreserved checkout: Allowed regardless of the status of other checkouts of the version Before check in, must be merged or discarded if any checkin has taken place 3 R 3 R U

Checking out a File: ClearCase Explorer

Checking out a File: Windows Explorer

Usage: Example: checkout | co [ -res/erved ] [-unr/eserved [ -nma/ ster ] ] [ -out dest-pname | -nda/ ta ] [ -pti/me ] [ -bra/nch branch-pname | -ver/sion ] [ -nwa/rn ] [ -c/omment comment | -cfi/le comment-file-pname | -cq/uery | -cqe/ach | -nc/omment ][ -q/uery | -nq/uery ] pname ... Checking out a File: Command Line Interface M:\nags_view\test\source>cleartool checkout file.txt Checkout comments for "file.txt": . Checked out "file.txt" from version "\main\9". (OR) M:\nags_view\test\source>cleartool cleartool> checkout -reserved -c "command line checkout" file.txt Checked out "file.txt" from version "\main\9". You must end the comment by typing “ . ” and Enter

A directory namespace is a list of the names of file and subdirectory elements that the directory contains Operations that change the directory namespace require a new directory version. These operations include Adding a new file or directory elements Renaming fie or directory elements Removing elements Moving file or directory elements Adding or removing VOB links The ClearCase GUI automatically checks out a directory and creates a new version if a change occurs to the directory namespace (some operations will prompt you to check out the directory) Using the CLI, you must check out/check in a directory to create a new version To change only file contents but not the directory namespace, you do not need to check out the directory Version Directories

Checking in a New Version Adds a new version to the version tree Removes the read/write copy of the file from the view storage area The checked in version becomes available to users using dynamic views and to the snapshot view users upon the next update Checking in Using CLI Usage: checkin | ci [-c comment | -nc] [-identical] pname… Example: M:\nags_view\test\source\NewFolder>cleartool ci -c "minor enhancements" nag.c Checked in "nag.c" version "\main\2".

Resolving Checkouts 3 R 3 R U Reserved Unreserved 1 Check out 3 4 2 Check in 1 Check out 2 Check out 3 4 3 Check in 5 U 4 Merge 5 Check in

What is a Version Tree? A hierarchical representation of an element in which all versions are logically organized. VOB 0 1 2 3 hello.c /main Element Name Branches R1 Label 0 1 2 /r2_int Versions

Version-extended Names Each version of an element has a unique identifier The extended naming symbol denotes a path into the version tree of an element @@ is the default extended naming symbol VOB 0 1 2 3 hello.c /main R1 0 1 2 /r2_int hello.c@@/main/r2_int/1 Version selected by your view

Files that are not under ClearCase source control Files that reside in the view; other users in other views do not see them Examples: Temporary files created during development or testing Files not yet added to source control Read/write copies of files checked out of source control What are View-private Files?

Branch type is a user-defined name that performs a unique pathname in the version tree Allows changes across multiple elements to be logically grouped together Allows different projects to use the same source at the same time Controls public/private work Isolates changes Temporary, such as new features that have not yet been tested Permanent, such as fixing a bug in a retired release Prevents roadblocks – development can proceed during an integration period Branching Enables Parallel Development hello.c /main R1 /r1_fix /r2_int /nag_r2 /chris_r2

Branch Type A user-defined name that forms a unique pathname in the version tree Allows changes across multiple elements to be logically grouped together Centralizes administrative control of branch names Main branch Integration branch Hello.c /main Util.c /main /r2_int /r2_int Using branch types unsures Consistent Tree structures

Working on Branches When working on a project team, you will most likely work on element branches other than /main A view config spec specifies which versions of the element appear in the view Edit our view config spec to select the correct branches and the correct versions

A default config spec is automatically set whenever you create a new view Rule 1: Select version of elements checked out to THIS view Rule 2: If no version is checked out, select the latest version on /main The Default View Config Spec Rule 1 Rule 2 Default Configuration Specification

A view config spec can use the –mkbranch clause to create branches automatically upon checkout: Rule 3 is interpreted as: Select the version of the element with the R1 label During checkout, automatically create the rel1_bugfix branch from the version labeled R1 Check out the 0 (zero) version on the rel1_bugfix branch Editing a Config Spec to Create Branches

Version Tree with Updated Configspec Before checkout into view with the config spec using the auto mkbranch rule After checkout; notice that checkout created the rel1_bugfix branch

Typical Workflow: Merging Merge work Merge work to integration area Merge work from integration area

Merging is the process by which ClearCase propagates changes from one branch to another A merge combines the contents of two or more files or directories into a new version of a file or directory After a merge, development can continue on both branches Future merges have no restriction in either frequency or direction ClearCase includes automated merge facilities for handling most merge scenarios Merging Overview 0 hello.c /main 1 2 3 0 1 2 /r2_int

Every file in a VOB is associated with an element type ClearCase uses element types to categorize and manage elements Not all ClearCase element types can be merged Element Types and Merging CAN be merged CANNOT be merged directory binary delta file html compressed file ms word file rose xml text file compressed text file xde

How ClearCase Merges Files and Directories Before Merge After Merge Base Contributor From Contributor Target (to) Contributor Merge Result

Integrating Parallel Development: Merging Policies The goal of merging is to integrate parallel development Each organization should define a merging strategy that works in their environment and which answers: When do we merge? How do we merge? Who performs merges? How often do we merge? Merging is two way Merge from main branch to bugfix branch, then merge from bugfix branch to main branch Merge from bugfix branch to main branch, then merge from main branch to bugfix branch

Merge Algebra A B C D E A (Deleted) C D R (Changed) X (Inserted) A B C Z (Changed) Q (Changed) A Deleted C Z (Changed) ? (Conflict) X (Inserted) Start Diff Merge Tool Base contributor version “ From” contributor version “ To” contributor version Merge Result

Types of Merges Merge tool prompts you to choose between merge contributors There are conflicting changes among the contributors Manual Automatic merge There are changes, but no conflicting merge points Automatic Non-trivial Merge result contains changes from the “from” contributor Base and Target contributor contain the same data from the “from” contributor Trivial Result Changes Type of merge

Merge Utilities In ClearCase, you can merge in one of three ways: Version Tree Browser Merge Manager Command line interface

Merging using Version Tree Browser Scenario: For element new doc merge v2 on /main with v1 on rel1_bugfix 1 Select the “from” version and then click Tools > Merge to 2 When the cursor changes to resemble a target, click the “to” version

Merging using Version Tree Browser (cont.) 3 Select Yes to perform the merge. 4 Click OK to confirm the merge

Merging using Version Tree Browser (cont.) If there are no conflicting changes, the merge proceeds automatically As a result of the merge, ClearCase: Copies the checked out file to file.contrib Places the results of the merge in the checked-out version of the file Records the merge in the VOB database 5 Check in the file to complete the merge

Merging with the Merge Manager The Merge Manager provides a graphical interface for locating files to be merged and for performing the merge Start > Programs > Rational > ClearCase > Merge Manager 1 Click on New

Merging with the Merge Manager (cont.) 2 Select the view 3 Select the specific element you want to merge

Merging with the Merge Manager (cont.) 4 Choose a method for selecting the version of each element to merge Merge from LATEST element on a selected branch Merge from element according to a specified label Use a ClearCase query language statement to select the “from” versions Merge elements selected by a particular view

Merging with the Merge Manager (cont.) 5 Provide additional information needed for the merge, then click Finish 6 Confirm the merge criteria, then click Find

Merging with the Merge Manager (cont.) 7 Click Yes to verify the merge elements 8 Click OK to start the merge

Merging with the Merge Manager (cont.) Base Contributor: The original version Contributor1: The version that you are delivering FROM Contributor2: The version that you are delivering TO Merge results pane Navigation Buttons: Use to move between merge points Merge Buttons: Click to move changes from the first, second, or third contributor pane to the merge results pane.

Usage: merge { –out output-pname | –to contrib-&-result-pname } [ –g·raphical [ –tin·y ] | [ –ser·ial_format | –dif·f_format | –col·umns n ] ] [ –bas·e pname | –ins·ert | –del·ete ] [ –nda·ta | –nar·rows ] [ –rep·lace ] [ –q·uery | –abo·rt | –qal·l ] [ –c·omment comment | –cfi·le comment-file-pname | –cq·uery | –cqe·ach | –nc·omment ] [ –opt·ions pass-through-options ] { –ver·sion contrib-version-selector ... | contrib-pname ... } Examples: Merge the version of file util.c in the current view with the most recent versions on the rel2_bugfix and test branches; suppress the creation of merge arrows. cleartool> merge –to util.c –narrows \ –version /main/rel2_bugfix/LATEST /main/test/LATEST Merge the version of file util.c , in view jk_fix , to version 3 on the main branch, placing the merged output in a temporary file. cleartool> merge –out \tmp\proj.out util.c@@\main\3 \jk_fix\users_hw\src\util.c Merge the version of file util.c to version 3 on the main branch, placing the merged output in a temporary file. cmd- cleartool> merge –abort –out /tmp/proj.out util.c@@/main/3 util.c Subtractive merge: remove the changes made in version 3 from file util.c . cleartool> merge –to util.c –abort –delete –version util.c@@\main\3 Merging from Command Line

Working with Elements Working with elements Adding files and directories to source control Comparing versions of elements Moving, renaming, and removing elements and versions Viewing an element history The lost+found directory

Working with Views Working with Views Finding checkouts Changing a checkout status Cancelling a checkout Specifying versions using version-extended names Removing a view

Adding Files to Source Control As you work on a project, you may create view-private files that you want to add to source control You can add Files and Directories Add files to source control GUI – Add to Source Control Command Line – mkelem Utility – clearfsimport When you add a file to source control, ClearCase: Determines the file type Creates an element Creates the /main branch and an empty version 0 By default, checks in the element and creates version 1

Adding Directories to Source Control Add directories to the source control the same way you add individual files When you add a directory to source control, files within the directory remain view-private

Adding Many Files or Directories When you must add a number of files or directories to source control use clearfsimport clearfsimport is a command-line utility that converts file system directories and files to ClearCase elements clearfsimport creates new elements or add new versions to existing elements NOTE: You must be the VOB Owner to run clearfsimport Usage: clearfsimport [-downcase] [-recurse] [-rmname] [-mklabel label] [-nsetevent] [-identical] [-master] [-comment comment ] [-unco] [-preview] source-name ... target-VOB-directory Example: To import the contents of C:\src into the source directory of test VOB C:> clearfsimport –recurse C:\src M:\nags_view2 \ test\source

Comparing File and Directory Versions ClearCase allows you to compare element and directory versions Can compare a version with a predecessor or with any other previous version in the tree In GUI, invokes graphical Compare tool that compares contents of files and directories

Comparing Directory Versions The Compare tool enables you to view, side-by-side, the elements appearing in two versions of a directory. CLI Procedure for File Comparison and Directory Comparison

Moving an Element From ClearCase Explorer only , drag and drop to move elements within a VOB CLI Procedure: Use the cleartool mv command to move an element from one VOB directory to another. Use cleartool relocate to move an element between VOBs.

Removing References to an Element Remove the name of an element or VOB symbolic link from a directory list The element still exists in the VOB Moving or removing elements creates new versions of the parent directories

Renaming an Element CLI Procedure To Remove Reference to an Element: >cleartool rmname hello.c To Rename an Element: >cleartool move hello.c hello1.c

Removing a Version When you remove a version, other versions before and after the removed version(s) remain accessible. If removing a non-text file element version, the data container is deleted If removing a text file element version, ClearCase logically removes the version from the data container. No disk space is recovered. The version-ID of a deleted version is never used. You CAN NOT delete a version from which there is currently a checkout Subsequent reference to a removed version produce an error

Removing an Element Removes an element COMPLETELY from the VOB; there is NO WAY to restore it Removes all references to it in ALL directory lists You can not remove elements that have checked-out versions To remove an element/version, you must be the element owner, VOB owner, or have ClearCase administrative rights CLI Procedure: Remove a Version: > cleartool rmver new.doc@@\main\rel1_bugfix \1 Remove an Element: > cleartool rmelem util.c

Viewing an Element History An element history is recorded in event records in the VOB A ClearCase operation, such as checkout, causes an event record to be created Event records include: who, what, when, where and comments associated with the event Events that change the content of elements are considered major, while other events are considered minor

The lost+found Directory Found in every VOB at the highest directory level Contains orphaned elements, which are elements that are no longer catalogued in any version of any directory Elements can become orphaned if a user: Cancels a checkout of a directory after adding a new element – it removes the directory element, but not the file elements created in it. Removes a directory element without removing the file elements within the directory

ClearCase enables you to search for checkouts based on user-defined criteria. Finding Checkouts Based on selection criteria, ClearCase displays a list of the checked out files in the Find Checkouts window.

Cancel a checkout when you do not want to save changes or want a fresh copy You can rename and save a view-private version of the file : filename.keep . If you do not save the file, all changes are lost You can cancel a checkout from Find Checkouts window Once you undo a checkout, your view selects the predecessor version Cancelling a Checkout

Enable you to specify a version that may not be visible in your dynamic view @@ ( extended-naming symbol ) denotes a path into the version tree of an element Specify integer versions hello.c@@\main\rel1_bugfix\9 User-defined version labels util.c@@\REL1.0 Using a standard name, you access the version of the file that your dynamic view selects: type hello.c To see a version other than the one selected by your dynamic view, use a version-extended pathname: type hello.c@@\main\rel1_bugfix\2 Selecting a Version Other Than Those in Your View

Views are temporary, task-related objects; once a specific development task or project is complete, remove the view Before removing a view, add all important view-private files to source control or copy them to another location Removing the view will: Clean up VOB references to the view Remove the view storage directory Remove the view tag and unregister the view Stop view server processes DO NOT use Windows Utilities to remove a view storage directory Removing a View

What is metadata? Kinds of ClearCase metadata Metadata uses Applying metadata (Use labels, attribute, and hyperlinks) ClearCase Metadata

A set of constructions and annotations that attach to ClearCase objects Allows you to organize, manipulate, and manage those objects Enables you to Find, list, sort, and retrieve information Access work faster and more directly Organize tasks Manage how development tasks are performed Capture information beyond what ClearCase captures by default Enforce policies What is metadata?

Kinds Branches ■ Labels Elements ■ Attributes Triggers ■ Hyperlinks Types Specific definitions of the kind dedicated to particular uses Instances One example of a given type applied to one or more ClearCase objects ClearCase metadata kinds share an implementation scheme: Create the metadata type Create an instance of that type Kinds of Metadata Kind : branch Type : rel1_bugfix Instance: hello.c@@/main/rel1_bugfix

Structuring the Project: Elements and Branches Elements Define elements storage and retrieval characteristics May be used to group elements for special handling Branches Provides areas for task isolation and integration Annotating the Project: Labels and Attributes Describe significant milestones, status flag, and tasks: Branch points Build Configurations Baselines Status messages Identify starting points for future projects Identify release configurations Metadata Uses

User-defined names that can be attached to versions Uniquely identify a version Identify a significant task or project milestone Typically static Using Labels

Name and value pair Can annotate any ClearCase object Use to represent properties that can have many possible values Example: BugNum = 22, 43, 54 Use to represent properties that change overtime Example: tested=“no”, “ready”, “yes”, “passed”, “failed” Using Attributes hello.c /main R2.1 /r2.1_bugfix BugNum = 22 tested=“failed” BugNum = 54 tested=“passed”

Triggers define actions to be performed in response to a ClearCase event Events are ClearCase operations that modify a VOB element including check out and check in Actions include launching batch files, executables, or another ClearCase operation Triggers are local to a single VOB Triggers support project policy implementation. Project policies are rules that: Enforce project methodology Automate routine operations Enforce site development policies Managing Project Policies: Triggers

Pre-event triggers Performed before the event Used to enforce policies Ex: A trigger that prevents anyone but project leads from declaring branch types Post-event triggers Performed after a successful event Used to provide information or initiate further actions Ex: A trigger that attaches an attribute with a particular bug fix number to a version upon check in Managing Project Policies: Triggers (cont.)

A logical connection between any two VOB objects Allow you to identify and preserve relationships between VOB objects Can show a relationship between objects in different VOBs Can show a relationship between objects in different VOBs Automatically created by merge operation Showing Project Relationships: Hyperlinks

Viewing Metadata Types: Type Explorer Start > Programs > Rational > ClearCase > Type Explorer Metadata types Metadata kinds

Applying a Label 1 In the Version Tree Browser , select the version you want to label, and then click Tools > Apply Label 2 Select the desired label, and then click Apply

Adding Attributes 1. Click on Custom tab on the Properties sheet of the object to be annotated. 2 Click Add Attribute on the shortcut menu. 3 Enter the Attribute type and Value, and then click OK 4 click OK

Hyperlinks can only be attached through the command line. Use cleartool mkhlink to attach hyperlinks to VOB objects Example : Create a hyperlink of type design_spec connecting the versions of a source file and design document labeled REL2. >cleartool mkhlink design_spec util.c@@\REL2 \users_hw\doc\util.doc@@\REL2 Created hyperlink "design_spec@685@\users_hw". Attaching Hyperlinks

Integrating Parallel Development

Topics Branching Branching – review Why branch? Types of branches Instantiating branch types Merging Performing special types of merges Unreserved Checkout Selective merge Subtractive merge

Branching - review Technique to isolate change and enable parallel development Controls the public and private nature of work Typically parallel branches are eventually merged into a resulting product CM,CA, or PL defines the organization branching and merging policies

Why Branch? When you Need project level parallel development of a comman base Want to isolate aspects of the product’s evolution Work on a long-range task and want to save and baseline your work (private branches) Are working on a new feature and don’t want to have an impact on other developers Need to organize your work by location for use with ClearCase Multisite

Types of Branches Integration branches /Main Project branches Release branches Feature branches Maintenance branches Developer branches MultiSite branches

Creating Branch Instances Branch type should exist Use –mkbranch clause in the config spec

Multi-Level Auto-Branching Element * CHECKEDOUT Element * /main/r2_int/pat_r2/LATEST Element * /main/r2_int/LATEST –mkbranch pat_r2 Element * R1 –mkbranch r2_int Rule 1: Rule 2: Rule 3: Rule 4: /main 0 1 /main 1 0 /pat_r2 /r2_int 0 C 0 File before checkout File after checkout

Merging an Unreserved Checkout You cannot check in an unreserved checkout if there are successor version The unreserved checkout must be merged with LATEST before you can check in

Selective Merge Selects changes from a specific versions from a branch to merge Use the –insert option with merge command No merge arrow in version tree browser

Selective Merge - Example 3 2 1 0 R 1 0 /r2_int /main /r1_bugfix 4 R1 Other bug fixes not relevant to /r2_int Bug fix to deliver to /r2_int via selective merge Bug fixe not relevant to /r2_int

Subtractive Merge Removes changes made in one or more of its predecessors from a checked-out version The –delete option indicates the version or range of versions to subtract No merge arrow in Version Tree Browser

Subtractive Merge - Example The multi-threaded algorithm implemented in element Versions 2 and 3 contains a fatal Flaw. /main 3 2 1 0 4 R Initial Code Faulty code Back out only these changes Cleartool merge –to hello.c – delete –version \main\r2_int\pat_r2\2 \main\r2_int\pat_r2\3

Creating Reports Report on ClearCase objects and events using cleartool subcommands Run reports using the ClearCase Report Builder

Cleartool sub commands Many ClearCase commands read data from a VOB, format it, and write to standard output Scope of reports can be Single Element Set of objects Entire VOB

Cleartool : Annotate Provides line-by-line details about changes to versions of an element Extracts information from element versions By default, writes its output to an .ann file

Cleartool : describe Lists info about VOB and VOB objects Descriptions of elements, versions, or other objects Labels attached to a particular version Hyperlinks and/or attributes attached to objects Predecessor versions of a particular version

Other commands Lshistory : lists events for VOB-database objects Lsvtree : lists the events in tree like structure

ClearCase Basics

Recommended

More Related Content

What's hot (20)

Similar to ClearCase Basics (20)

Recently uploaded (20)

ClearCase Basics