vspacer
 
vspacer
 
Valid XHTML 1.0!
 
Valid CSS 1.0

ClearCase Commands : File and Version Information

 

ZDS ClearCase Commands
 
20. To change the comment for a revision.

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).

Cleartool is realistic, and accomodating, so you have a chance to correct and revise comments as needed.

chevent -c "comment" -rep file.name@@/main/version#
will replace an existing comment for revision n on the main trunk.

chevent -c "comment" -rep *
will replace the existing comments on the latest revisions of all files in the current directory.




21. To change the content description for a file.

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.

To change this subsequently:

chevent -c "content description" -rep file.ext@@/main/version#




22. To list the history (versions with comments) of a file.

cl lshist -all -since 08:00 file.ext
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.

cl lshist -all -since 31-Jul-96.23:59




24. To find out the file_type of a file.

This is useful to confirm that a file is stored by Cleartool in an appropriate format.

Element type : Use with
text_file : Flat ascii text file
file : Any binary file that you don't mind Cleartool compressing for storage.
compressed_file : Binary file that's already compressed and you want Cleartool to store as-is.

To find this out enter:
describe file.ext
or
describe *




25. To setup cleartool to send email on a file change.

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:

#1: Get VOB access.

#2: Create an e-mail notification script in unix format and add it to atria. For example:

Courtesy aric kollmyer:#!/bin/sh
mailx -s "Cleartool warning: Reminder on zLib update" supercon
ENDMAIL New Version of dialog.cpp
create: $CLEARCASE_PN by:
$CLEARCASE_USER Comment string:
-------------
Someone has really done it now, they installed a new version of zLib!.
This may cause problems as I made the following patches to :
dialog.cpp in the zDialogFrame::create() method to correct .....
So, you had better re-test with the new zApp libraries linked in and
verify that trhe new library fixes this problem
-Me Self (555) 123-4567 Quincy, CA meself@hotmail.com
ENDMAIL

#3: Register the script file as a trigger.
cl mktrtype -nc -element -postop checkout -exec
<nameAndFullPathOfScriptFile> <nameOfTrigger>

Example:

cl mktrtype -nc -element -postop checkout -exec
/gl/vobs/netman/src/zapp/source/glenayre.sh glenTrigger

#4: Attach the trigger to an existing element:

cl mktrigger -nattach <nameOfTrigger> <nameOfElementToAttachItTo>

Example:

cl mktrigger -nattach glenTrigger dialog.cpp

The examples shown will send e-mail document to supercon when dialog.cpp is checked-out.

Download

ClearCase Commands (116KB)

   


Back to top | ZDS Home | This article updated January 14, 2004.