|
|
A dynamic view is an MVFS directory tree that enables dynamic access to VOB elements. Dynamic views contain nearly all the artifacts created during the software development process, whether or not they are under ClearCase control. These artifacts include the following:
Selected versions of elements (actually stored in VOB storage pools)
Files that are being modified (checked-out file elements, stored in the view's private storage area)
Directories that are being modified (checked-out directory elements, maintained in the VOB database)
Shareable and unshared derived objects built by users working in this view (stored in the view's private storage area) and configuration records that correspond to these derived objects
Shared derived objects originally built in another view and then winked in to this view (stored in VOB storage pools)
View-private objects: miscellaneous files, directories, and links that are not under Clearcase control and appear only in this view (stored in the view's private storage area).
Each dynamic view on a host exists as a directory under the view root directory. On UNIX computers, the default view root directory is /view. On Windows computers, the default view root directory is drive M.
In addition to the various view storage directories, the view root contains the special file .specdev. If this file is missing or damaged, attempts to access dynamic views on the host will generate this error message:
cleartool: Error: Unable to open file "viewroot": ClearCase object not found.
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, all of which are created and modified 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 |
Subdirectory .s of the view storage directory is the root of a subtree that implements the view's
private storage area. On UNIX platforms, .s can be either a local directory or a UNIX symbolic link to a directory on another UNIX computer or Network Attached Storage device.
The private storage area holds several kinds of objects:
View-Private objects. A view-private object is a file-system object-file, directory, or UNIX 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: In a dynamic view on UNIX, you cannot create any of the UNIX special file types (sockets, named pipes, character device files, or block device files).
Checked-out versions. 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 build script by clearmake, omake, or by any program invoked by clearaudit. When the DO becomes shareable, it is promoted and a corresponding derived object is created in the VOB database.
NOTE: Even after the DO becomes shared, a copy of it remains in the view's private storage area. DOs can consume a great deal of space and should be scrubbed when they are no longer needed. 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, omake, 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 (config recs) 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. 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 when it is deleted with a rmelem command.
See the description of the recoverview command for more information about recovering stranded files.
The view database subdirectory, db, contains these files, all of which are created and modified by 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 | 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.
A dynamic view provides transparent access to versions of elements. Each time you access an element, the view_server evaluates the view's config spec and selects a version of the element. It uses the following procedure for resolving element names to versions.
User-level software (for example, an invocation of the C compiler) references a pathname. The ClearCase MVFS, which processes all pathnames within VOBs, passes the pathname to the appropriate view_server process.
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.
When it finds a matching version, the view_server selects it and has the MVFS pass a handle to that version back to the user-level software.
In addition to storing view-private files, a dynamic view's private storage area contains derived objects built in that view by clearmake (and, on Windows, omake). Nonshareable and unshared derived objects typically consume the most disk space in a view's private storage area. When a derived object is created, both its data container file and its configuration record are stored in the view. The first time the derived object is winked in to another view or promoted to the VOB, the view interacts with the VOB as follows:
The configuration record is moved to the appropriate VOB database or databases. If the build script creates derived objects in several VOBs, each VOB database gets a copy of the same configuration record.
The data container is copied (not moved) to a VOB storage pool. If the winkin was done by a clearmake or omake build, the original data container remains in view storage, to avoid interference with user processes that are currently accessing the data container. If the winkin was done with the winkin or view_scrubber -p command, the data container in the view is removed after it is promoted to the VOB storage pool.
From time to time, you (or the view owner) may find it worthwhile to remove the redundant storage containers from views with the view_scrubber utility. (See Chapter 20, Administering View Storage.)
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
