Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Topics
Objectives............................................................................................................ 2-2
Checkout/Checkin Model..................................................................................... 2-4
Checking Out a File: File Browser......................................................................... 2-7
What Is a Version Tree?...................................................................................... 2-12
Viewing Versions of an Element Graphically........................................................ 2-14
What Are View-private Files? .............................................................................. 2-15
Branching Enables Parallel Development ............................................................ 2-16
The Default View Config Spec ............................................................................ 2-19
Creating a New Branch Automatically................................................................. 2-22
Objectives
Objectives
Upon completing this module, you should be able to:
Explain the checkout/checkin model
Explain the difference between a reserved and
unreserved checkout
Check out/check in files and directories
Define version trees and branches and explain
how branches enable parallel development
Edit a view config spec to automatically create a
branch
Checkout/Checkin Model
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
Types of Checkout
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
6
Checkout types are only important when more than one person is checking out on the
same 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 that
holds 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. If
several views have unreserved checkouts, the first view to check in the element creates
the successor; developers working in other views must merge the checked-in changes
into 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 the
code
• You are using ClearCase with legacy code, and have multiple developers using the
same versions of files, working on different sections. Several people need to check
out the same version. You can use unreserved checkouts to do this
We discuss resolving unreserved checkouts later in this module.
2
Select Versions>
Checkout from
the menu.
1
Select the
file to
checkout.
CLI Procedure
Usage:
checkout | co [-reserved] [-unreserved] [-c comment | -nc] pname ...
Example:
/vobs/Hardware/src% cleartool checkout -c "making sample
changes" util.c
Checked out "util.c" from version “/main/5".
Example:
Versioning Directories
Versioning Directories
To change the directory namespace you must create
a new directory version
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
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 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 not
exist in other directory versions.
If you are working through the CLI, you must check out/check in the directory to create
a new version if you change the directory namespace.
You don’t need to check out directories when creating view-private files.
10
A checkin copies the modified checked-out version back to the VOB and uses it to
create a new version of the element. The checked-out copy of the version is deleted
from view storage.
Check in can be done in almost all GUI ClearCase Windows that list the checked-out
file version.
If the versions are identical and you still want to check in, you must click the check box
in the Check In dialog box; otherwise, ClearCase tells you that you cannot check in a
version identical to its predecessor.
If you attempt to check in an unreserved checkout without a merge (and there is a
successor version), you get a message indicating that the file needs to be merged prior
to 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".
Resolving Checkouts
Resolving Checkouts
11
12
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 versions
of an element. Every element has one main branch, which represents the principal line
of development, and may have multiple subbranches, each of which represents an
independent line of development.
ClearCase supplies the /main branch as the trunk of every tree. Other branches are
user-created.
The 0 (zero) version on the main branch is empty. The 0 version on any other branch
contains 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 annotate
element versions. Labels can be used in ClearCase to mark project milestones, to
identify starting points, to mark important configurations.
Version-extended Names
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
13
Each version of an element has a unique identifier that marks the version’s position in
the 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 the
course.
14
ClearCase graphically depicts an element’s version tree in the Version 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
15
View-private files are files that are not under source control in ClearCase. Files that you
have not yet added to source control are view-private. Also, copies of files that you
check out of source control to modify are view-private while they exist in your local
workspace.
Parallel development allows multiple users to access the same sources without
competing for checkouts. Work can continue simultaneously on various branches and
later be integrated.
ClearCase has unlimited branching capabilities, allowing you to organize your
development 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
17
ClearCase allows each organization the flexibility to develop and implement its own
branching policies. Branching strategies are typically defined by a ClearCase
administrator or project leader and can vary widely from organization to organization.
As part of implementing a branching strategy, the administrator or project leader
defines a series of branch types. Branch types allow changes across multiple elements
to 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
Working on Branches
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 your view
config spec to
select the correct
branches and the
correct versions
18
Rule 1
Rule 2
The config spec is the filtering mechanism for a view. It is a set of ordered rules that
selects the versions of elements visible to the view.
When you create a view, ClearCase assigns it a default config spec. The default config
spec can select versions in any active VOB for any element, as all elements have a main
branch and a 0 (zero) version on that branch. Although the 0 version is empty, it is still
considered 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 and
working down the list. As each rule is evaluated, ClearCase determines if a version of
the element matches the rule. If a version matches, that version is selected to appear in
the 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.
Rule 1
Rule 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 be
used in the config spec.
21
You can edit a view config spec to create a branch automatically. Whenever you check
out an element for the first time, the rules in the config spec create the branching
structure you define using the –mkbranch clause. Creating branches with the config
spec 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 labeled
version 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 #2
in its selection. It selects either the CHECKEDOUT version or the LATEST on the branch
created when the -mkbranch clause was executed.
22
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.
Screenshot of how
new branch looks in
version tree browser
23
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, and
as checkouts occur, the config spec’s first two rules will preempt evaluation of the third
rule and the -mkbranch rule will not be evaluated again for this element (unless the
branch is removed).
Module Review
Module Review
How does ClearCase protect files from being
modified inadvertently?
What happens when you check out a file?
What is the difference between a reserved and an
unreserved checkout?
When do you need to create a new version of a
directory?
What happens when you check in a file?
What is a version tree?
What is a view default config spec?
24
Module Lab
Module Lab
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
25