17.4 Snapshot Views

A snapshot view uses a host's native file system to hold versions of file and directory elements that have been loaded from a VOB. After the snapshot view has been created, versions of file and directory elements must be copied, or loaded, into the view's snapshot view directory. The snapshot view directory is usually on the local host but can be located on any host that the view server can access over the network, even if that host does not have ClearCase installed (see the mkview reference page for information on the -vws option).

In addition to copies of versions, the snapshot view directory can contain view-private file-system objects that are not under ClearCase control. It also contains some files that ClearCase creates to help manage the view.

Any snapshot view storage directory contains two subdirectories:

Snapshot views cannot contain derived objects. You can run clearmake and omake in a snapshot view, but none of their build auditing and build avoidance features will be enabled.

A snapshot view must have an associated view_server process. Some ClearCase hosts cannot run view_server processes. Snapshot view directories can reside on these hosts, but the view storage directories for these snapshot views must reside on a host that can run a view_server process.

For administrative purposes, it is important to know whether the view storage directory of a snapshot view is a subdirectory of the snapshot view directory. For example, when you back up or move a snapshot view, you must take account of both the snapshot view directory and the view storage directory. For more information, see Chapter 19, Backing Up and Restoring Views and Chapter 21, Moving Views.

Snapshot View Directory Tree

The snapshot view directory tree is part of the host's 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 elements, the root of this directory tree (referred to as the snapshot view's root directory) contains the following files and subdirectories, which are created and modified ClearCase commands and should never be modified in any other way:

view.dat

A read-only text file used to identify the current directory as part of a view. (.view.dat on UNIX.)

view.stg or a generated directory name

A directory used to maintain the view. (.view.stg on UNIX.) For a colocated view storage directory only, the default name of this directory is named view.stg; for any other view storage directory, this directory has a generated name. Certain view configurations require that this directory be located somewhere outside the snapshot view's root directory. (Refer to the mkview reference page for information on view configurations.)


NOTE: When referring to a snapshot view, many ClearCase commands require the snapshot-view-directory-pname argument (rather than an argument specifying the view-tag). By reading the view.dat file, which is in the root directory of the snapshot view, ClearCase can find the view storage directory.

View Storage Directory

The snapshot view's view-storage directory is used by ClearCase to manage the contents of the snapshot view directory. It contains the following files and subdirectories, all of which are created and modified by ClearCase commands and should never be modified in any other way:

.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 view's view_server process.

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 accounting information.

.identity

On UNIX, a subdirectory whose zero-length files establish the view's owner and group memberships.

identity.sd

On Windows, a security descriptor created for views stored in a FAT or FAT32 file system. Views stored in NTFS file systems include security descriptors in the file system ACL and do not need this file.

.s

A subdirectory that implements the view's private storage area.

db

A subdirectory containing the files that implement the view's embedded database.

.view

A file that lists the view's universal unique identifier (UUID) and other attributes

view_db.state

A file that records the current state of the view.


View Database

The view database subdirectory, db, contains these files, all of which are created and modified ClearCase commands and should never be modified in any other way:

view_db.dbd

A compiled database schema, used by embedded DBMS routines for database access. The schema describes the structure of the view database.

view_db_schema_version

A schema version file, used by embedded DBMS routines to verify that the compiled schema file is at the expected revision level.

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.

How a Snapshot View Selects Versions

A snapshot view has a config spec that, in conjunction with the view's load rules, determines which versions of elements are loaded into the snapshot view directory by the cleartool update command. Each time you update the view, the view_server evaluates the view's config spec, selects a version of each element defined in the view's load rules, and copies a new version of each element in the snapshot view directory if the one already there does not match the selected version. It uses the following procedure for resolving element names to versions.

  1. The view_server attempts to locate a version of the element that matches the first rule in the config spec. If this fails, it proceeds to the next rule and, if necessary, to succeeding rules until it locates a matching version.

  2. When it finds a matching version, the view_server selects it, updates the view's database, and passes a handle to that version to the CCFS server, which copies it into the snapshot view directory.