Beruflich Dokumente
Kultur Dokumente
Where "atag" is the view-tag (the "name" of the view which should be a mnemonic name that you can
easily remember) and storage-location is the location of a place on a disk where the view can store
information.
Modifying Files
Checkout
To modify an element you need to check it out. Do this with the following command:
cleartool co anelement
where "anelement" is the name of the file or directory you want to check out.
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 anelement
where "anelement" is the name of the file or directory you want to check in. Once you check-in an
element, the changes you made to that element are usable by everyone on your project.
Uncheckout
If you want to cancel a checkout, you can do so with the following command:
Creation
To create a new file, you can use whatever editor or command you would normally use to create the
file. The new file will be a view-private entity until you take the next step to put it under ClearCase
control.
cleartool co thedirectory
cleartool mkelem thefile
cleartool ci thedirectory
After this sequence is performed, the file "thefile" is still checked-out and can be modified further
before you check it in.
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 thedirectory
cleartool rmname anelement
cleartool ci thedirectory
After this sequence, "anelement" is no longer listed in subsequent versions of "thedirectory". It is,
however, still listed in previous versions of the directory. If, at a later date you want to re-add
"anelement" to a new version of "thedirectory" (or any other directory), you can do so easily.
Renaming Elements
Renaming an element is 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 newdirectory
cleartool mv anelement newdirectory
cleartool ci .
cleartool ci newdirectory
Renaming an element is also accomplished using the "cleartool mv" command except the old directory
and the new directory are the same.
cleartool co .
cleartool mv anelement anewname
cleartool ci .
In subsequent versions of the directory, the name "anelement" will not appear, having been replaced
by "anewname" but the name "anelement" will still appear in prior versions of the directory. Both the
names "anewname" and "anelement" will still refer to the same element; only the name associated
with the element in the directory will have changed.
Getting Information
About Views
What 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" in the tradition of 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
cleartool edcs
Your favorite editor , as specified by the environment variable WINEDITOR (first choice), VISUAL
(second choice), or EDITOR (third choice) 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.
About Files/Directories
cleartool lsco
Lists checkouts of elements in the current directory that are checked-out to the
current view.
Lists checkouts of elements in the current directory and below that are checked-out
to the current view.
Lists checkouts of elements in the current directory that the current user has
checked-out.
Please refer to the ClearCase Reference Manual for more detailed information about the "cleartool
lsco" 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.
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 this file/directory?
To view a graphical representation of the version tree associated with an element you can use the
"xlsvtree" command.
cleartool lsvtree –g anelement
You can view a textual representation of the version tree associated with an element with the "cleartool
lsvtree" command.
Lists information about "anelement" 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.
DOS bigots will appreciate the intuitive nature of the Unix equivalent of 'Help':
'man' (aka Manual Pages)
cl<return>
The prompt will change to cleartool.
exit<return>
or
quit<return>
Warning! Be aware that if you exit from Cleartool back to the shell after having
moved around in the directory tree within Cleartool, that you will NOT be returned
to the directory that you were in when you entered Cleartool from the shell.
The pwd (present working directory) command can help you keep track of where
you are.
cl xlsvtree filename
or
xcleartool
The xlsvtree graphics viewer is a powerful tool for viewing the version tree of a
file. It is very useful for visual diffing of one version of the file against another,
labelling versions or moving labels around.
ClearCase Commands : File Checkin Checkout
Cleartool will prompt for a comment if you do not use the third format to supply
one.
Other team members can then see who has the file out and why.
When you check the file back in this text will be presented as the default ci
change description, which you can override. If you are forethoughtful about the
comment most often it will not need to be re-typed when you do the checkin.
The file checked out stays in the same directory but the permission changes from
read only to read/write.
cl unco file.ext
Instead, you will have to do a tap dance to get the version you want in your view:
#1. cl co file.ext
You can then change tmpfile as required, cp/copy it to the atria directory with the
correct name, enter cleartool again and check the file in. Exit cleartool to the shell
to rm/delete the temporary file. Using a tmp_name will help ensure that you don't
screw up and delete the atria archive file by mistake!
Remember to do this at the end of your session to make sure you have not
forgotten to check back in files and directories.
Other team members cannot access the files for update until you have checked
them back in, and will have to waste time diffing and merging your changes with
theirs if they are forced to use private copies.
cl lsco -all
Cleartool will display the comment you entered at co time as the default. You
may override this if you want to.
To check in, or check out multiple files at once with the same comment:
cl ci -c "comment" *
cl co -c "comment" *
ClearCase Commands : Labels
cl lstype -lbtype
cl mklbtype BETA_1.1B
This is typically done for alpha, beta, final releases so that the entire set of files
with the label can be built.
will move existing label MY_LABEL down to the latest revision of each file in the
directory, and below, from which you invoke this command.
You can do lots of mix and match to find what you want.
ClearCase Commands : File and Version Information
Many revision control tools won't let you change a comment once committed, on
grounds of theology (Tichy didn't permit it), or control freakieness (typically MIS
installations).
When you set up a file initially on atria with -mkelem, you can use the -c
"comment" qualifier to record a description of the contents of the file.
will list all changes made to the file since the time specified.
23. To Find out what files have been worked on since a given date.
It is sometimes very useful to get a list of all the changes made to the source tree
since a given date.
You may want to cause e-mail to be sent to email handle 'supercon' when a
particular file has been updated.
This is particularly useful, for example, if you have patched the source in a
commercial library and you want to be sure that when the library is upgraded
your changes do not get overwritten, as the newest version of the library may or
may not have corrected the error your patches peviously corrected.
The e-mail notification acts as a helpful reminder to re-test for the bug which was
encountered in the earlier version, and re-update and re-build the commercial
library if the library vendor did not fix the problem.
How to do it:
#2: Create an e-mail notification script in unix format and add it to atria. For
example:
Example:
Example:
The examples shown will send e-mail document to supercon when dialog.cpp is
checked-out.
ClearCase : Directory Operations
#1 First checkout the directory under which you want to create the new sub-
directory.
cl co -c "Add directory xxx" .
#2 mkdir xxx
These last two steps will ensure that someone else can later manipulate the
directory without having to come back to you to beg for the privilege!
Eg: /src/ui/thunk_ar
#1 Change to the directory you want to rename eg: /ui/thunk_ar and check it out:
cl co .
#2 Checkout the directory above the directory you want to rename : eg /ui
cl cd..
cl co .
#1 First, you have to checkout the directory, because adding a file will change
the directory. Enter a checkout comment which can also serve as the check in
comment later.
NOTE! This assumes that the new element has an extension that is known to
Cleartool. If not, and you get a gobbledegook message 'Cant pick element type
from...' then you must specify an element type eg:
#6 You should check that you have set up the file with an apppropriate storage
type. See: Tip 24 'To find out the file type of a File'.
30. To use symbolic links avoid duplicating an archive file in different directories.
Rather than duplicate the file, we can place a link in directory /../VOBS/.../B to
point to the 'real' archive file in directory A.
co -unreserved
cl
This will remove the archive from the view, but it is still accessible and can be
viewed or retrieved if you need it again at some later time.
Warning! If you use rm filename outside Cleartool ie at the shell level the file is
GONE!
more .@@/main/5/file.ext@@/main/LATEST
Replace '5' with the last version of the directory that contained the file.
Instead of more you can use less - see man less for info.
ClearCase Commands : Branches
cl lstype -brtype
#1 cl mkbrtype Eagle
and enter appropriate comments (doesn't matter where in the tree you are).
#1 Use 'catcs' (Tip 23 : Look at your configspec) to ensure that your view is
currently set to the main line.
#5 In the root directory you will find a FILExxxx log, listing all the files merged.
Print it.
Use xlsvtree or something equivalent to diff the checked out file against the predecessor
file on the main-line.
Verify the merged file is the way you want it and edit it if not.
Build the app to verify the changes are (syntactically) valid.
Regression testing the app would be nice.
Checkin the verified files to the mainline.
- rm the file.contrib files. Try not to rm the file object by mistake.
Bring up the latest mainline and latest branch .dlg files in a resource editor and
hand tool the changes!
ClearCase Commands : Releases
#2 IMPORTANT! Make sure that you have commented out with the '#' symbol:
#element * /main/LATEST
Failure to do this will mean that later file versions updated AFTER the labelled
versions will get into the build!
Write down the label for the release you want eg 'RELEASE_2.02'.
Get it right!
Save the configuration, exit, and reply yes to confirm the configspec change.
#4 Do a:
dir s: /s > release.xxx
to do a recursive directory listing of the s: source drive using the view set by the
new configspec, and pipe the result to a file.
This is useful when you want to do a code review prior to a new release.
In the directory at the top of the src tree:
This will recursively examine the source tree and output to pooh.bar a list of the
files with head versions with no label ie the changes since the last label was
applied to all the files.
ClearCase Commands : Administrator
Warning! Don't do this without being sure you know what you are doing!
This command will chop off the latest version from a file, including versions
above it if the version is not the latest one!
rmver file.exe@@/main/version#
catcs
This will display the directives that Cleartool is currently using to filter files into
your logical 's:' drive. eg:
edcs