DEMO

This is a walkthrough of basic CCFD operations to get you started.

See ccfd.html for the full man page and more examples.

BASIC OPERATION

First, note below that we have a ClearCase versioned element named foo.txt, version /main/9.

    % ls -l foo.txt
    -r--r--r--   1 dsb      ccusers     1491 Apr  1 14:30 foo.txt
    % ct ls -s foo.txt
    foo.txt@@/main/9

It is not checked out and therefore not writeable, of course:

    % cp /etc/motd foo.txt
    cp: cannot create foo.txt: Permission denied

So now we start up ccfd and look again:

    % ccfd
    % ls -l foo.txt 
    -rw-r--r--   1 dsb      ccusers     1491 Apr  1 14:30 foo.txt
    % ct ls -s foo.txt
    foo.txt@@/main/9

It's still foo.txt@@/main/9 but now it looks like it is writeable! Let's try it:

    % cp /etc/motd foo.txt 
    Checked out "/vobs/tmp/ccfd/foo.txt" from version "/main/9".
    % cat foo.txt 
    Sun Microsystems Inc.   SunOS 5.8       Generic February 2000

A checkout was automatically triggered when we tried to copy a file over it, and foo.txt now has the contents of that file. In other words the write operation succeeded.

    % rm  foo.txt
    Checked out "/vobs/tmp/ccfd" from version "/main/28".
    Removed "foo.txt".

Removing the file checks out the parent dir and does a ``cleartool rm''.

    % ct unco -rm .
    Checkout cancelled for ".".
    % mv foo.txt bar.txt
    Checked out "/vobs/tmp/ccfd" from version "/main/28".
    Moved "foo.txt" to "bar.txt".

And renaming it again automatically invokes the required ClearCase operations.

That's the basic idea: think of CCFD as ``Just-in-time ClearCase''. It retrofits ClearCase-awareness to any existing program written in any language, automatically, without need for source code or relinking.

STARTING VIEWS

Now you don't see it:

    % ct lsview myview
    myview               /net/u10/data/ccase/vwstore/dsb/myview.vws

(Note: view not running.) But now you do!

    % ls /view/myview/vobs/tmp/ccfd
    aa         apue-our   d1         foo.txt    ml         stat-1.6
    apue       apue-tar   d2         hs.c       motd.txt   sys.c
    apue-full  bar        dsb        links.pl   our.tar
    apue-gtar  bar.txt    foo        lnk        skel
    % ct lsview myview            
    * myview               /net/u10/data/ccase/vwstore/dsb/myview.vws

How did that work? Same way - ccfd intercepted the stat() system call used by ls; when stat() failed and it saw that the path begins with ``/view/'', it ran ``cleartool startview'' and tried again.

CREATING NEW CLEARCASE OBJECTS

By default, CCFD affects only operations on existing ClearCase elements. However, the -m flag will cause it to turn new filesystem objects into elements as well:

    % ccfd -m
    % cp /etc/motd .  
    Checked out "/vobs/tmp/ccfd" from version "/main/53".
    Created element "/vobs/tmp/ccfd/motd" (type "text_file").
    Checked in "/vobs/tmp/ccfd/motd" version "/main/1".
    % ln -s motd slink   
    Link created: "slink".
    % mkdir foo.d
    Created directory element "foo.d".

CHECKING IN

Modified elements are left checked-out by default. The -i flag will cause them to be checked in at program exit time:

    % ccfd -m -i -- cp /etc/group . 
    Checked out "/vobs/tmp/ccfd" from version "/main/54".
    Created element "/vobs/tmp/ccfd/group" (type "text_file").
    Checked in "/vobs/tmp/ccfd/group" version "/main/1".
    Checked in "/vobs/tmp/ccfd" version "/main/55".

However, note that brand-new file elements are always checked in at creation time. This is analogous to the way ``Add to Source Control'' works in modern ClearCase/Windows releases.

VERBOSITY

By default, the normal ClearCase messages such as Checked out "foo" from version "/main/32" are allowed to flow to stdout. The -q flag will suppress these, whereas -x will show the CC commands the same way sh -x does:

    % ccfd -m -i -q
    % ct ls -s motd 
    motd@@/main/1
    % cp /etc/group  motd
    % ct ls -s motd
    motd@@/main/2

METHODS OF INVOCATION

There are a variety of ways to get into a CCFD environment. Examples: