DESCRIPTION

A view provides a workspace in which users can access versions of ClearCase elements and other file-system objects that are outside of ClearCase source control. There are two kinds of views:

• Dynamic views, which provide transparent access to versions of elements in the VOB and to view-private objects. Each time you access an element through a dynamic view, the view's view_server process evaluates the view's config spec and selects a particular version of the element. Thus, such a view updates itself with new versions created in other views.
• Snapshot views, which contain copies of versions of specified elements, along with view-private objects. The view never updates itself with new versions created from other views. Instead, the update command reevaluates the view's config spec and loads the newly selected versions into the view.

This reference page discusses both a view's physical data structures and the way file system data appears to a user process through a view. Each type of view is discussed separately.

Dynamic Views: The File System

A dynamic view is an MVFS ( multiversion file system) directory tree that enables dynamic access to VOB elements.

Dynamic Views: View Storage Directory

A dynamic view is implemented as a standard directory tree, whose top-level directory is termed the view storage directory. The directory contains these files and subdirectories:

.access_info	A file of view access event information that is periodically updated by the view server.
.pid	A one-line text file that lists the process-ID of the associated view_server process, currently running on the host where the view storage directory resides.
.view	A file that lists the view's universal unique identifier (UUID) and attribute
	For descriptions of the other lines in this file, see view_server reference page.
admin	A directory that contains administrative data related to the amount of disk space a view is using. Use space -view to list this data.
config_spec	A file that stores the view's current config spec, in the form displayed by catcs.
.compiled_spec	A modified version of config_spec, which includes ClearCase accounting information.
.identity	A subdirectory whose files establish the view's owner and group memberships. Only the view's creator has access rights to this subdirectory. It has the same structure as the like-named subdirectory within a VOB storage directory. See the vob reference page for more information.
.s	A subdirectory that implements the view's private storage area. See the Dynamic Views Private Storage Area section.
db	A subdirectory containing the files that implement the view's embedded database. See Dynamic Views: View Database.

Dynamic Views Private Storage Area

Subdirectory .s of the view storage directory is the root of a subtree that implements the view's private storage area. If the view was created with mkview -ln, then .s is actually a (UNIX-level) symbolic link, pointing to a remote storage area. The private storage area holds several kinds of objects:

VIEW-PRIVATE OBJECTS. A view-private object is a file-system object-file, directory, or link-created by a standard program within a VOB directory. Such objects are stored only within the view's private storage area. No VOB maintains any record of such objects.

NOTE: You cannot make view-private files that represent types of file system objects that are not mentioned above. For example, you cannot create the following types of view-private files: named pipes, character device files, or block device files.

CHECKED-OUT FILES. A checked-out version is a file created by the checkout command. This file is an editable copy of the version being checked out.

A checked-out version is very much like a view-private file, except that there is a corresponding object in the VOB database: the special "placeholder" version with the CHECKEDOUT version label.

UNSHARED DERIVED OBJECTS. An unshared derived object is a data container created by execution of a makefile build script by clearmake or by any program invoked by clearaudit. A corresponding derived object is created in the VOB database if you are using a dynamic view.

NOTE: An unshared derived object remains in the view's private storage area even after the DO becomes shared. Promotion of the DO involves copying, not moving, the data container. The winkin command and view_scrubber utility remove unshared derived objects from a view's private storage area.

NONSHAREABLE DERIVED OBJECTS. A nonshareable derived object is a data container created by execution of a makefile build script by clearmake or by any program invoked by clearaudit, from a dynamic view. No information about the DO is stored in the VOB database. When you use winkin or view_scrubber -p to convert a nonshareable DO to a shareable DO, the command promotes the DO's data container to the VOB, and removes the data container from view storage.

CONFIGURATION RECORDS. The file view_db.crs_file in the .s subdirectory is actually part of the view's database, as described in the following section. It is the part that stores the configuration records of derived objects built in the view.

STRANDED FILES. The directory lost+found in the .s subdirectory contains stranded files, that is, files that were view-private and are no longer accessible through normal ClearCase or Attache operations. (Only dynamic views have lost+found directories.) A file becomes stranded when there is no VOB pathname through which it can be accessed. For example:

• A VOB can become temporarily unavailable, for example, by being unmounted.
• A VOB can become permanently unavailable, for example, by being deleted.
• A VOB directory can become permanently unavailable, by being deleted with a rmelem command.

See the description of the recoverview command for more information about recovering stranded files (recoverview does not apply to snapshot views.)

Dynamic Views: View Database

The view database subdirectory, db, contains these files:

view_db.dbd	A compiled database schema, used by ClearCase embedded DBMS routines for database access. The schema describes the structure of the view database. The mkview command creates this file by copying ccase-home-dir/etc/view_db.dbd.
view_db_schema_version	A schema version file, used by ClearCase embedded DBMS routines to verify that the compiled schema file is at the expected revision level. The mkview command creates this file by copying ccase-home-dir/etc/view_db_schema_version.
view_db.d0n view_db.k01	Files in which the database's contents are stored.
vista.*	Database control files and transaction logs.
view_db.crs_file	Stores the configuration records of nonshareable and unshared derived objects. This file resides in subdirectory .s of the view storage directory, allowing it to be remote. Compressed copies of the configuration records are cached in a view-private file, .cmake.state, located in the directory that was current when the build started. This speeds up configuration lookup during subsequent builds in the view.

The view database keeps track of the objects in its private storage area: view-private objects (files, directories, and links), checked-out versions, nonshareable derived objects, and unshared derived objects.

Snapshot Views: The File System

The snapshot view directory tree is part of the native file system (as opposed to the directory tree of a dynamic view, which is part of the MVFS, or multiversion file system). In addition to copies of ClearCase elements, the root of this directory tree (referred to as the snapshot view's root directory) contains the following files and subdirectories:

.access_info	A file of view access event information that is periodically updated by the view server.
.view.dat	A read-only text file used by ClearCase to identify the current directory as part of a ClearCase view.
.view.stg	A directory used by ClearCase to maintain the view. (By default, the directory is named .view.stg; you can specify a different name with the -vws option to mkview.) Certain view configurations require that this directory be located somewhere outside the snapshot view's root directory. (Refer to the mkview reference entry for information on view configurations.)

NOTE: When referring to a snapshot view, many ClearCase commands require the snapshot-view directory-pname (as opposed to the view's view-tag). By reading the view's.view.dat file, which is in the root directory of the snapshot view, ClearCase can find all of the files and directories associated with the view.

Snapshot Views: View-Storage Directory

The view-storage directory (by default, .view.stg), is used by ClearCase to maintain the view. It contains the following files and subdirectories:

admin	A directory that contains administrative data related to the amount of disk space a view is using. Use space -view to list this data.
.pid	A one-line text file that lists the process-ID of the associated view_server process, currently running on the host where the view storage directory resides.
.view	A file that lists the view's universal unique identifier (UUID) and attributes.
config_spec	A file that stores the view's current config spec, in the form displayed by catcs.
.compiled_spec	A modified version of config_spec, which includes ClearCase accounting information.
.identity	A subdirectory whose files establish the view's owner and group memberships. Only the view's creator has access rights to this subdirectory. It has the same structure as the like-named subdirectory within a VOB storage directory. See the vob reference page for more information.
.s	A subdirectory containing empty subdirectories.
db	A subdirectory containing the files that implement the view's embedded database. See Dynamic Views: View Database.
view_db.state	A file that records the current state of the view.

Snapshot Views: View Database

The view database subdirectory, db, contains these files:

view_db.dbd	A compiled database schema, used by ClearCase embedded DBMS routines for database access. The schema describes the structure of the view database. The mkview command creates this file by copying .ccase-home-dir/bin/view_db.dbd.
view_db_schema_version	A schema version file, used by ClearCase embedded DBMS routines to verify that the compiled schema file is at the expected revision level. The mkview command creates this file by copying ccase-home-dir/bin/view_db_schema_version.
view_db.d0n view_db.k01	Files in which the database's contents are stored.
vista.*	Database control files and transaction logs.

For a snapshot view, the view database keeps track of the loaded VOB objects and checked-out versions in the view.

Comparison of Dynamic and Snapshot Views

Snapshot views:

• Require an update operation periodically

• Provide optimal performance for developing source files and for prototype builds
• Facilitate working from a remote location
• Use the load command to copy a specified set of source files into the view

Work in a snapshot view when any of these conditions is true:

• You want to optimize build performance to achieve native build speed.
• You want to work with source files under ClearCase control when you are either disconnected from the network or connected to the network intermittently from a remote location.
• You want to access a view from a computer that is not a ClearCase host.
• Your development task doesn't require the ClearCase build auditing and build avoidance features.

Dynamic views:

• Show changes to elements in the VOB as they are made (and thus do not require an update operation)
• Support the ClearCase build auditing and build avoidance features
• Provide access to all elements in all mounted VOBs without using load

Work in a dynamic view when any of these conditions is true:

• Your development task requires audited builds.
• You want to enable derived object sharing.

• You prefer to use a view that is updated during development.

The table below compares features of snapshot views and dynamic views.

A Comparison of View Features
Feature	For dynamic views	For snapshot views
Storage requirements	You need enough disk space to store any view-private files or view-private directories.	You need enough disk space to store the copies of the loaded elements and any view-private files or view-private directories.
To access ClearCase elements	You start the view and mount VOBs on your computer.	Your view's config spec loads elements into the view.
Version selection	For any element in a mounted VOB, the view always selects the version specified by the config spec. You can traverse the view-extended namespace to see any version of any element in any mounted VOB.	You use the update command to update the elements loaded into the view. You can see only the version of an element that is loaded into your view.
VOB symbolic links and VOB hard links	The link is traversed each time you access the object.	The version to which the link resolves at update time is copied into the view.
Version that is checked out	By default, the checkout operation checks out the latest version on a branch, regardless of what the config spec specifies.	The checkout operation checks out the file loaded in your view, which may not be the latest version on a branch.
Build features	You can use the clearmake features of build auditing and build avoidance.	You can use clearmake, but the build auditing and build avoidance features are disabled.
Sharing the views with other team members	View objects are accessible to other team members through ClearCase's view-extended namespace.	View objects are accessible to other team members if you tell themthe snapshot view directory path. Snapshot views are not accessible through ClearCase's view-extended namespace.