ASPL ClearCase and SCM
check in your changes frequently.
Toolkit Quick Reference
Reference Materials
Command Line Help
Help for individual ClearCase commands can be
obtained using the following syntax:
# Display syntax summary for <command>
cleartool help <command>
# Display complete manual for <command>
cleartool man <command>
Help for individual SCM Toolkit commands can be
obtained using the following syntax:
<SCM_Toolkit_command> --help
ClearCase
http://dsg.britain.agilent.com/clearcase_manuals/7.0.0
SCM Toolkit
http://dsg.britain.agilent.com/scmtoolkit
Inquest
http://dsg.britain.agilent.com/inquest
Views
How many views do I need?
One per discrete task associated with an Inquest
change request and an integration view per release
stream. Views should be regarded as "inexpensive"
entities which are easily created and destroyed.
Create one for each task you need and delete
when that task is done.
ASPL ClearCase and SCM Toolkit Quick Reference
We do not backup view storage so make sure you
How to create a view
The newview command run on a UNIX system is
used to create views. For a development view:
newview –p <project> -r <release> -c
<CR>
For an integration view:
newview –p <project> -r <release> -i
For a baseline view:
newview –p <project> -r <release> -b
<label>
Accessing code through a view
useview
Accessing code through a ClearCase view is done
with the useview command. Simply enter the
command and choose the required view from the
list presented. On UNIX the view will then be set in
the current shell. On Windows it will be mapped as
a sub-directory of the P: drive.
How to remove a view
The rmview command run on a UNIX system is
used to remove views, either type rmview and
select the view from the menu or:
rmview –view <view-name>
Modifying Files
In the follow examples, element is the name of
the file or directory you are working with.
Agilent Restricted
Checkout
To modify an element you need to check it out. Do
this with the following command:
cleartool co <element>
Checkin
Once you are happy with the changes you have
made to a checked-out element, you can check it in
with the following command:
cleartool ci <element>
Uncheckout
If you want to cancel a checkout, you can do so
with the following command:
cleartool unco <element>
Creating New Files
Creation
To create a new file, you can use whatever editor
or tool you would normally use to create the file.
The file will be a view-private entity until you take
the next step to put it under ClearCase control.
Putting a file under version control
To put a file under ClearCase control you must first
check-out the directory that will contain the file,
issue the command to put the file under version
control, and check-in the directory containing the
new file. Here are the commands to perform these
steps from the directory to contain the file
cleartool co .
cleartool mkelem <the_file>
cleartool ci .
Page 1 of 4
After these steps are performed, the_file is still
checked-out and can be modified before it is
checked in.
Putting a directory under version control
To create a new version controlled directory in
ClearCase, as with a new file, you must check-out
the directory which will contain it, issue the
command to create the new directory, and check-
in the parent directory.
cleartool co .
cleartool mkdir <the_directory>
cleartool ci .
After these steps are performed, the_directory
is still checked-out so new file and directory
elements can be added to it.
Deleting Elements
To remove an element you should use the
cleartool rmname command. This command
removes the name of the specified element from
the directory in which it is contained. Similar to
placing an element under ClearCase control, you
must first check-out the directory containing the
element to be removed, do the cleartool
rmname of the element, and then check-in the new
version of the directory. Here is an example:
cleartool co .
cleartool rmname <element>
cleartool ci .
After this sequence, element is no longer listed in
subsequent versions of the directory. It is,
ASPL ClearCase and SCM Toolkit Quick Reference
however, still listed in previous versions of the
directory. If, at a later date, you want to re-add
element to a new version of the directory (or any
other directory), this can be done and you retain all
the version history.
Moving and Renaming Elements
Moving an element follows a process similar to
deleting it. First you check-out the old directory
containing the element, and you also check-out the
new directory to which the element is to be
moved. Then you use the cleartool mv
command to perform the move operation. Be sure
to check-in the old and new directories when you
are done.
cleartool co .
cleartool co <new_directory>
cleartool mv <element> <new_directory>
cleartool ci .
cleartool ci <new_directory>
Renaming an element is also accomplished using
the cleartool mv command except the old and
new directories are the same.
cleartool co .
cleartool mv <element> <new_name>
cleartool ci .
In subsequent versions of the directory, the name
element will not appear, having been replaced by
new_name but the name element will still appear
in prior versions of the directory. Both the names
new_name and element will still refer to the same
Agilent Restricted
element; only the name associated with the element
in the directory will have changed.
More About Views
Which view am I in?
At any given time you can tell what view you are in
by issuing the following command:
cleartool pwv
pwv means "print working view" similar to the
UNIX command pwd for "print working directory"
What is my "config-spec"?
Recall that a configuration specification (config-
spec) is the set of rules that tells ClearCase what
configuration of elements you want to work with.
You can see that set of rules by issuing the
following command:
cleartool catcs
How do I change my config-spec?
You can edit your config-spec by issuing the
following command. When using SCM toolkit there
is almost no case where editing a config-spec will
be required.
cleartool edcs
Your chosen editor as specified by the environment
variables WINEDITOR, VISUAL, or EDITOR will be
invoked for the editing operation. If none of these
environment variables is set then vi will be
invoked for the editing operation on UNIX systems
and Notepad will be invoked for the editing
operation on Windows systems.
Page 2 of 4
Information about Files/ Directories
What is checked-out and to whom?
If you want to see who has what checked-out, you
can use the cleartool lsco command. This
command has a number of possible arguments to
use depending on the specific information you
want. Here are some common ones:
Lists all checkouts of elements in the current
directory.
cleartool lsco
List checkout information about the element
element.
cleartool lsco <element>
List all checkouts of elements in the current
directory and below.
cleartool lsco -recurse
List checkouts of elements in the current directory
which are checked-out to the current view.
cleartool lsco -cview
List checkouts of elements in the current directory
and below which are checked-out to the current
view.
cleartool lsco -cview -recurse
List checkouts of elements in the current directory
which the current user has checked-out.
cleartool lsco -me
List checkouts of elements in the current directory
that the user with login id "fred" has checked-out.
ASPL ClearCase and SCM Toolkit Quick Reference
cleartool lsco -user fred
Please refer to the ClearCase Reference Manual for
more detailed information about the cleartool
lsco command.
What is the change history of this
file/directory?
If you want to see the change history associated
with a particular element, you can use the
cleartool lshistory command.
cleartool lshistory <element>
Where element is the element under ClearCase
control.
What versions of what files/directories am I
looking at?
To see exactly what versions of elements are being
projected to you by your view and why, you can
use the cleartool ls command.
cleartool ls
What are the differences between this
version of a file/ directory and a different
version?
To view the differences between the versions of an
element visible in your view and another version of
the element you can use the cleartool diff
command.
To graphically view the differences between the
version of element selected by your view and its
immediate predecessor version.
cleartool diff -g -pred <element>
Agilent Restricted
To graphically view the differences between the
version of element selected by your view and
version 5 on the main branch of element.
cleartool diff -g <element>
<element>@@/main/5
You can also use this command without the -g
option to present the difference information to you
textually rather than graphically.
See the cleartool diff entry in the ClearCase
Reference Manual for more detailed information
on these commands.
What does the version tree look like for a
file/directory?
To view a graphical representation of the version
tree for an element, you can use the lsvtree
command.
cleartool lsvtree -g <element>
You can view a textual representation of the
version tree of an element with the cleartool
lsvtree command.
cleartool lsvtree <element>
I want more information about this element?
You can get more detailed information about a
particular element with the cleartool
describe command.
cleartool describe <element>
Lists information about element such as the
version selected by your view, who created it and
when, the comment associated with the version,
the element type and the predecessor version.
Page 3 of 4
SCM Toolkit
Getting a list of my change requests
buglist
You can get a list of the change requests assigned
to you and in the open state by typing the
buglist command. This will list the Inquest CR ID,
project and headline for each of your change
requests.
What change request does my current view
relate to?
buginfo
When working in an SCM Toolkit development
view entering the buginfo command will display
the Inquest CR ID, project, state and headline
information for the change.
Finding out what has changed on a branch
lsbranch
The lsbranch command will tell you all the
elements modified on a development or
integration branch when run in the context of a
view.
In an integration view it can be used to see
elements changed, who changed them, when they
were delivered and what change request they were
working on.
lsbranch -fixes –who -time
Where you are applying baselines to your code
lsbranch can be used to identify all the changes
on an integration stream since a particular label.
Again in an integration view:
ASPL ClearCase and SCM Toolkit Quick Reference
lsbranch -since <label> -fixes
Identifying code, baselines
Baselines allow you to return to a previous state of
the code base at any future time. The mkbaseline
command is used to apply a ClearCase label across
all the VOBs in your development project and the
SCM Toolkit configuration files.
To apply a simple sequential label in an integration
view use:
mkbaseline -sequence
SCM Toolkit automatically increments the
sequence number to create a label of the form:
<project>_<release>_<sequence>
e.g. TOOKIT_5.XX_00001
To apply a specific baseline label in an integration
view use:
mkbaseline –label <label>
Closing completed development branches
and re-opening them later
Developing with SCM Toolkit can result in a large
number of branches. To keep the ClearCase version
tree clean and for general project housekeeping,
development branches should be closed down
when completed. This is done using the
end-branch command.
end-branch –p <project> -r <release> -c
<CR>
This will lock the branch in ClearCase and mark it as
obsolete. If the branch is subsequently required it
can be re-opened:
Agilent Restricted
reopen-branch –p <project> -r <release>
-c <CR>
Integrating code changes - rebase
Including changes made on an integration stream
into your development branch is done using the
rebase command in your development view. By
default, rebase will merge all VOBs associated
with your project. To perform a partial rebase the
following options can be used:
Rebase only files:
rebase -files
Rebase only directories:
rebase –directories
Rebase only a sub-directory:
rebase <path>
The rebase operation will attempt to carry out
merges automatically. Where this is not possible
the ClearCase graphical merge tool will be
displayed allowing you to complete the merge.
Please note that you will need to have an X
windows tool running on your PC e.g. Reflection X
Integrating code changes –deliver
Having completed a rebase and included all
changes from the integration stream into your
development branch you can build and test. To
introduce your completed development changes
into the integration stream use the deliver
command in an integration view for your release.
deliver –c <CR>
Page 4 of 4