04_scm271_ecc_s02

8/9/2019 04_scm271_ecc_s02

1/26

Copyright IBM Corp. 2003 2 - 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Module 2Working with Files Under Source Control

1

IBM Software Group

Essentials of Rational ClearCase

Module 2: Working with Files Under Source Control

Topics

Objectives............................................................................................................ 2-2Checkout/Checkin Model..................................................................................... 2-4Checking Out a File: File Browser......................................................................... 2-7What Is a Version Tree?...................................................................................... 2-12Viewing Versions of an Element Graphically........................................................ 2-14What Are View-private Files? .............................................................................. 2-15Branching Enables Parallel Development ............................................................ 2-16The Default View Config Spec............................................................................ 2-19Creating a New Branch Automatically................................................................. 2-22

8/9/2019 04_scm271_ecc_s02

2/26


2 - 2 Copyright IBM Corp. 2003


Objectives

2

Explain the checkout/checkin model

Explain the difference between a reserved andunreserved checkout

Check out/check in files and directories

Define version trees and branches and explainhow branches enable parallel development

Edit a view config spec to automatically create abranch

Upon completing this module, you should be able to:

Objectives

8/9/2019 04_scm271_ecc_s02

3/26

Module 2 - Working with Files Under Source Control



Typical Workflow: Work on Files

3

Typical Workflow: Work on Files

8/9/2019 04_scm271_ecc_s02

4/26




Checkout/Checkin Model

4

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

ClearCase protects versions in the VOB from accidental modification, even by anadministrator. File elements are read-only until they are checked out.

At checkout, ClearCase makes a read/write copy of the element available to a view. Itcreates a placeholder in the version tree as the potential successor version.

At checkin, ClearCase determines if the file is automatically accepted as the successorversion or if it is necessary to first integrate the file with other potential successorversions.

8/9/2019 04_scm271_ecc_s02

5/26




View Before and After Checking out hello.c

5

View Before and After Checking out hello.c

In the example above, before checkout, a read-only version of hello.c is visible.

Upon check out, the object is copied to the views physical storage area. A write-privileged file is now available in the view to work on.

The VOB knows which elements are checked out to what view.

8/9/2019 04_scm271_ecc_s02

6/26




Types of Checkout

6

Types of Checkout Reserved checkout:

Default checkout

Has exclusive rights to next place onversion tree

No checkins can be made on the samebranch until the checkout is resolved

Only allowed if no other reservedcheckouts exist for the branch

Unreserved checkout: Allowed regardless of the status of other

checkouts of the version

Before check in, must be merged ordiscarded if any checkin has taken place

Checkout types are only important when more than one person is checking out on thesame branch.

The default status for a checkout is reserved. On a reserved checkout, ClearCase

creates a placeholder version. The successor version can come only from the view thatholds the reserved checkout. This means:

No one can check in to the branch before the reserved checkout is resolved The checkout has exclusive rights to the next version in the tree

An unreserved checkout does not guarantee the right to create the successor version. Ifseveral views have unreserved checkouts, the first view to check in the element createsthe successor; developers working in other views must merge the checked-in changesinto their own work before they can check in.

Scenarios where you would use an unreserved checkout:

To help a fellow developer debug code, you need to add a debug statement to thecode

You are using ClearCase with legacy code, and have multiple developers using thesame versions of files, working on different sections. Several people need to checkout the same version. You can use unreserved checkouts to do this

We discuss resolving unreserved checkouts later in this module.

8/9/2019 04_scm271_ecc_s02

7/26




Checking Out a File: File Browser

7

Checking Out a File: File Browser

2

Select Versions>Checkout fromthe menu.

1

Select thefile tocheckout.

CLI Procedure

Usage:

checkout | co [-reserved] [-unreserved] [-c comment | -nc]pname ...

Example:

/vobs/Hardware/src% cleartool checkout -c "making samplechanges" util.c

Checked out "util.c" from version /main/5".

8/9/2019 04_scm271_ecc_s02

8/26




Checking Out a File: Command Line Interface

8

Checking Out a File: Command Line InterfaceUsage:

Example:

/vobs/Hardware/src% cleartool checkout hello.c

Checkout comments for "hello.c":

Working on cleaning up the code.

Checked out "hello.c" from version

/main/r2_int/2".

You MUST end thecomment by typing. and Enter

checkout | co [-reserved] [-unreserved] [-branchbranch-pname |-version] [-c comment| -cfilepname | -cq | -cqe | -nc] pname ...

8/9/2019 04_scm271_ecc_s02

9/26




Versioning Directories

9

Versioning Directories To change the directory namespace you must create

a new directory version

The ClearCase GUI automatically checks out adirectory and creates a new version if a changeoccurs to the directory namespace (some operationswill prompt you to check out the directory)

Using the CLI, you must check out/check in adirectory to create a new version

To change only file contents but not the directorynamespace, you do not need to check out thedirectory

A directory namespace is a list of the names of file and subdirectory elements that thedirectory contains.

Operations that change the directory namespace require a new directory version. These

operations include: Adding new file or directory elements Renaming file or directory elements Removing elements Moving file or directory elements Adding or removing VOB links

If you change the directory namespace while working through the Windows GUI,ClearCase automatically checks out/checks in the directory and creates a new version.On UNIX, users are prompted to checkout the directory on certain commands.

Since ClearCase creates versions of directories, file elements seen in your view may notexist in other directory versions.

If you are working through the CLI, you must check out/check in the directory to createa new version if you change the directory namespace.

You dont need to check out directories when creating view-private files.

8/9/2019 04_scm271_ecc_s02

10/26




Checking in a New Version

10

Checking in a New Version Adds a new version to the version tree

The checked-in version becomes available to dynamicview users and, upon the next update, to snapshot viewusers

A checkin copies the modified checked-out version back to the VOB and uses it tocreate a new version of the element. The checked-out copy of the version is deletedfrom view storage.

Check in can be done in almost all GUI ClearCase Windows that list the checked-outfile version.

If the versions are identical and you still want to check in, you must click the check boxin the Check In dialog box; otherwise, ClearCase tells you that you cannot check in aversion identical to its predecessor.

If you attempt to check in an unreserved checkout without a merge (and there is asuccessor version), you get a message indicating that the file needs to be merged priorto check in.

CLI Procedure

Usage:

checkin | ci [-c comment | -nc] [-identical]pname ...Example:

/vobs/Hardware/src% cleartool ci -c "minor enhancements"util.c

Checked in "util.c" version /main/2".

8/9/2019 04_scm271_ecc_s02

11/26




Resolving Checkouts

11

Resolving Checkouts

When you check in a reserved checkout, it becomes the successor version.

Unreserved checkouts are a little more complicated. If no versions have been addedsince the unreserved checkout occurred (due to check in by reserved or unreserved

checkouts), and there are no reserved checkouts existing, the user can check in withouta merge.

Otherwise, a merge must take place with the latest version on the branch to implementthe changes in the unreserved checkout.

The merge occurs FROM the latest on the branch to the unreserved checkout to ensurethe changes arent conflicting, and once the merge is complete, the unreservedcheckout can be checked in.

In the diagram, the numbers outside the version tree indicate the sequence ofoperations.

8/9/2019 04_scm271_ecc_s02

12/26




What Is a Version Tree?

12

What Is a Version Tree?

A hierarchical representation of an element in which

all versions are logically organized.

ClearCase organizes the different versions of an element in a VOB into a version tree.The element version tree has branches.A branch specifies a linear sequence of versionsof an element. Every element has one main branch, which represents the principal line

of development, and may have multiple subbranches, each of which representsanindependent line of development.

ClearCase supplies the /main branch as the trunk of every tree. Other branches areuser-created.

The 0 (zero) version on the main branch is empty. The 0 version on any other branchcontains the same contents as the version from which the branch originated.

The R1 on version 2 of the /main branch is a label. You can use labels to annotateelement versions. Labels can be used in ClearCase to mark project milestones, toidentify starting points, to mark important configurations.

8/9/2019 04_scm271_ecc_s02

13/26




Version-extended Names

13

Version-extended Names Each version of an element has a unique identifier

The extended naming symbol denotes a path intothe version tree of an element

@@ is the default extended naming symbol

Each version of an element has a unique identifier that marks the versions position inthe version tree.

You can use extended version names to specify a particular version of an element other

than that which your view has selected. You learn more about this topic later in thecourse.

8/9/2019 04_scm271_ecc_s02

14/26




Viewing Versions of an Element Graphically

14

Viewing Versions of an Element Graphically

ClearCase graphically

depicts an element version

tree in the Version Tree

Browser

ClearCase graphically depicts an elements version tree in theVersion Tree Browser.

CLI Procedure

Usage:

lsvtree [-g] [-short] [-all] [-nmerge] [-nco]pname ...

Example:

/vobs/Hardware/src% cleartool lsvtree hello.c

hello.c@@/main

hello.c@@/main/2 (R1)

hello.c@@/main/r2_int

hello.c@@/main/r2_int/2

hello.c@@/main/3

8/9/2019 04_scm271_ecc_s02

15/26




What Are View-private Files?

15

What Are View-private Files?

Files that are not under ClearCase source control

Files that reside in the view; other users in other viewsdo not see them

Examples:

Temporary files you create while developing source code

Files not yet added to source control

View-private files are files that are not under source control in ClearCase. Files that youhave not yet added to source control are view-private. Also, copies of files that youcheck out of source control to modify are view-private while they exist in your local

workspace.

8/9/2019 04_scm271_ecc_s02

16/26




Branching Enables Parallel Development

16

Branching Enables Parallel Development

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

Parallel development allows multiple users to access the same sources withoutcompeting for checkouts. Work can continue simultaneously on various branches andlater be integrated.

ClearCase has unlimited branching capabilities, allowing you to organize yourdevelopment effort in whatever way makes sense for your organization.

Examples of parallel development efforts, or branches, might include:

Current development branches

Maintenance branches

Port branches

Feature branches

Experimental branches

8/9/2019 04_scm271_ecc_s02

17/26




What Is a Branch Type?

17

What Is a Branch Type? A user-defined name that forms a unique pathname in

the version tree

Allows changes across multiple elements to be logicallygrouped together

Centralizes administrative control of branch names

ClearCase allows each organization the flexibility to develop and implement its ownbranching policies. Branching strategies are typically defined by a ClearCaseadministrator or project leader and can vary widely from organization to organization.

As part of implementing a branching strategy, the administrator or project leaderdefines a series ofbranch types. Branch types allow changes across multiple elementsto be logically grouped together.

Common branch types include:

Task branches for short-lived tasks that involve a small percentage of files Private development branches allow multiple developers to work on a common

code base Integration branches provide a buffer between private development branches

and the main branch

Branch type examples:

rel1_bugfix Fixing bugs for an old release

alex_exp Experimental work by an individual

wizard_features Development for specific features

8/9/2019 04_scm271_ecc_s02

18/26




Working on Branches

18

When working on a project team, you will most likelywork on element branches other than /main

A view config spec specifies which versions of the

element appear in the view

Edit your view

config spec to

select the correct

branches and thecorrect versions

Working on Branches

8/9/2019 04_scm271_ecc_s02

19/26




The Default View Config Spec

19

A default config spec is automatically set whenever

you create a new view

The Default View Config Spec

Rule 1Rule 2

Rule 1: Select version of element checked out to

THIS view

Rule 2: If no version is checked out, select the latestversion on /main

The config spec is the filtering mechanism for a view. It is a set of ordered rules thatselects the versions of elements visible to the view.

When you create a view, ClearCase assigns it a default config spec. The default configspec can select versions in any active VOB for any element, as all elements have a mainbranch and a 0 (zero) version on that branch. Although the 0 version is empty, it is stillconsidered the latest on the branch if no other versions exist.

The rules of a config spec are evaluated in order, line by line, starting at the top andworking down the list. As each rule is evaluated, ClearCase determines if a version ofthe element matches the rule. If a version matches, that version is selected to appear inthe view. If no version matches, the next rule is evaluated.

The config spec rules are evaluated for each element.

The CHECKEDOUT rule means checked out to this view.

8/9/2019 04_scm271_ecc_s02

20/26




Editing a View Config Spec

20

Editing a View Config Spec You can edit the config spec to select versions on a

branch other than /main

Rule 1: Select version of element checked out toTHIS view

Rule 2: If no version is checked out, select the latest

version on the r2_int branch

Rule 1Rule 2

For parallel development, you can edit your config spec to select versions other than/main/LATEST.

In many organizations, the project manager creates a config spec template that

developers paste into their individual config specs.Note: When working in a mixed Windows and UNIX environment, slashes (/) must beused in the config spec.

8/9/2019 04_scm271_ecc_s02

21/26




Editing a Config Spec to Create Branches

21

Editing a Config Spec to Create Branches A view config spec can use themkbranch 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 r2_int branchfrom the version labeled R1

Check out the 0 (zero) version on the r2_int branch

You can edit a view config spec to create a branch automatically. Whenever you checkout an element for the first time, the rules in the config spec create the branchingstructure you define using the mkbranch clause. Creating branches with the configspec ensures you are implementing a consistent branching structure.

In the example on the slide, the config spec creates a r2_int branch from the R1 labeledversion of an element. The version that is checked out is version 0 on the r2_int branch.When it is checked in, it becomes version 1 on the r2_int branch.

Once the branch is created and the checkout occurs, the view never gets past Rule #2in its selection. It selects either the CHECKEDOUT version or the LATEST on the branchcreated when the -mkbranch clause was executed.

8/9/2019 04_scm271_ecc_s02

22/26




Creating a New Branch Automatically

22

Creating a New Branch Automatically

Change your config spec to create a branch when you

check out elements that have an R1 label.

Edit the config spec, inserting the -mkbranch rule in the appropriate location.Remember, the config spec attempts to apply these rules in the order they appear.When creating the config spec, do so with an if/then approach for each rule.

8/9/2019 04_scm271_ecc_s02

23/26




Creating a New Branch Automatically (cont)

23

Creating a New Branch Automatically (cont)

Screenshot of hownew branch looks in

version tree browser

Before checkout into viewwith the config spec usingthe auto mkbranch rule

After checkout; noticethat checkout created ther2_int branch

The CHECKEDOUT rule is selecting this version, not the /main/r2_int/LATEST rule.Once checked back in, the /main/r2_int/LATEST rule will select the version, andas checkouts occur, the config specs first two rules will preempt evaluation of the thirdrule and the -mkbranch rule will not be evaluated again for this element (unless the

branch is removed).

8/9/2019 04_scm271_ecc_s02

24/26




Module Review

24

How does ClearCase protect files from beingmodified inadvertently?

What happens when you check out a file?

What is the difference between a reserved and anunreserved checkout?

When do you need to create a new version of adirectory?

What happens when you check in a file?

What is a version tree?

What is a view default config spec?

Module Review

8/9/2019 04_scm271_ecc_s02

25/26




Module Lab

25

In this lab, you perform the following tasks:

Edit a config spec to automatically create branches

View an element version tree

Check out/check in files

Create a view-private file

Module Lab

8/9/2019 04_scm271_ecc_s02

26/26


2 - 26 Copyright IBM Corp 2003

Date post:	30-May-2018
Category:	Documents
Upload:	jagadeesh
View:	212 times
Download:	0 times

04_scm271_ecc_s02

Documents