| Prev | Next | ||
Each ClearCase VOB stores a variety of information related to, but
distinct from, the contents of file system objects. This information is
termed meta-data.
Operating systems also support certain kinds of meta-data. For example, a file's time-modified stamp is information pertaining to the file that is not actually in the file.
Operating systems also support certain kinds of meta-data. For example, a file's time-modified stamp is information pertaining to the file that is not actually in the file.
As users enter ClearCase commands, meta-data records are created automatically. These records include “who, what, when, where, and why” information regarding such operations as:
In particular, the record of a software build — a configuration record
— includes a “bill of materials”, listing (along with other
information) exactly which versions of source elements were used. This
provides both complete build auditing and guaranteed rebuildability.
Users can also create meta-data annotations explicitly, attaching them to file system objects. A user-defined annotation might indicate:
- creation of new elements, and new versions of existing elements
- creation of user-defined annotations
- software builds
Users can also create meta-data annotations explicitly, attaching them to file system objects. A user-defined annotation might indicate:
- ... that a particular version of an element was used in Release 4.31
- ... that the benchmark score on a particular executable was 19.3
- ... that two elements in different directories need to be kept synchronized
A VOB's meta-data is stored in its VOB database,
within the VOB storage directory. ClearCase includes commands for
listing (and in some cases comparing) the contents of previously
created meta-data records (Figure 3-1).
Users can access file system objects through their meta-data. This makes it possible (and easy) to define, reproduce, and maintain configurations of file system objects. For example, “all the versions labeled REL4.31” might constitute the configuration of files that was used to build a particular product release.
Meta-data also plays a fundamental role in ClearCase's tools for implementing development policies and procedures. For example, a project's source files might be partitioned into several classes using meta-data annotations. Then, different development policies might be applied to each class of source file.
Users can access file system objects through their meta-data. This makes it possible (and easy) to define, reproduce, and maintain configurations of file system objects. For example, “all the versions labeled REL4.31” might constitute the configuration of files that was used to build a particular product release.
Meta-data also plays a fundamental role in ClearCase's tools for implementing development policies and procedures. For example, a project's source files might be partitioned into several classes using meta-data annotations. Then, different development policies might be applied to each class of source file.
ClearCase supports numerous kinds of user-defined meta-data, all of which share the same implementation scheme:
For example, Figure 3-2 illustrates the mechanism by which a version label is attached to a version object.
The following sections briefly describe the several kinds of user-defined meta-data. Included are cross-references to discussions, in other chapters, of how users and administrators employ these mechanisms.
- Some user (typically, an administrator or project leader) defines a meta-data item for use within a particular VOB, by creating a type object in that VOB.
- Thereafter, users can create instances of the type
object. This is typically described as “attaching”, “assigning”, or
“instancing” the meta-data; it creates a pointer in some VOB object,
referencing the type object.
The following sections briefly describe the several kinds of user-defined meta-data. Included are cross-references to discussions, in other chapters, of how users and administrators employ these mechanisms.
A mnemonic identifier called a version label can be attached to any version of an element. A version label (for example, REL3.1.5) can often be used instead of the system-assigned version-ID (for example, /main/12) to specify a particular version of an element.
As Figure 3-3 indicates, the same version label can be used in many elements. It is also true that multiple labels can be assigned to the same version; for example, the same version of a rarely-modified element might “accumulate” many labels: REL3.0, REL3.1, REL3.1.5, and so on.
Like branches, version labels play a pivotal role in organizing and describing the development environment. A release engineer might assign version label REL3.1.5 to the set of source versions used in the build of a particular release. At any subsequent point, this configuration of versions can be referenced in a variety of contexts as “all the versions labeled REL3.1.5” (the shaded versions in Figure 3-3).
As illustrated in Figure 3-2, a version label is an instance of a label type object.
As Figure 3-3 indicates, the same version label can be used in many elements. It is also true that multiple labels can be assigned to the same version; for example, the same version of a rarely-modified element might “accumulate” many labels: REL3.0, REL3.1, REL3.1.5, and so on.
Like branches, version labels play a pivotal role in organizing and describing the development environment. A release engineer might assign version label REL3.1.5 to the set of source versions used in the build of a particular release. At any subsequent point, this configuration of versions can be referenced in a variety of contexts as “all the versions labeled REL3.1.5” (the shaded versions in Figure 3-3).
As illustrated in Figure 3-2, a version label is an instance of a label type object.
An attribute is a user-defined
annotation in the form of a name/value pair. Attributes can be attached
to many kinds of objects (whereas version labels can be attached only
to versions). Following are some examples of attributes:
Attributes have a multitude of applications, including:
An attribute is an instance of an attribute type object (Figure 3-4).
| Name | Kind of Value | Example |
| QAed | string | “Yes” |
| CodeQuality | integer | 3 |
| QAedBy | string | "george" |
| ECOnum | integer | 8987 |
| Benchmark | real (floating point) | 34.1 |
| LastQAed | time | 4-Apr.08:45 |
- Bug tracking — Each version involved in the fix for Bug #8987 might be assigned the attribute BugNumber/8987.
- Quality control
— Every version of a module might be assigned a CodeQuality attribute,
with values between 1 (worst) and 10 (best). Every element might be
assigned a TestProc attribute, whose value names a corresponding test
procedure.
- Requirements tracing
— Attributes can be attached to the hyperlinks that implement
requirements tracing, to provide additional information about the
relationship. (See “Hyperlinks / Hyperlink Types”.)
A hyperlink is a user-defined
logical arrow that connects two elements, branches, versions, or VOB
symbolic links. The objects can be in the same VOB, or in different
VOBs. Either end of a hyperlink can be annotated with a text string. Figure 3-5 illustrates a common application of hyperlinks, requirements tracing.
In this example, the version of a source module that implements a new algorithm is logically connected by a DesignFor hyperlink to the version of a design document that describes the algorithm. Subsequent versions of both elements implicitly inherit the connection between the versions that are linked explicitly.
Some additional examples:
In this example, the version of a source module that implements a new algorithm is logically connected by a DesignFor hyperlink to the version of a design document that describes the algorithm. Subsequent versions of both elements implicitly inherit the connection between the versions that are linked explicitly.
Some additional examples:
- Informal dependencies
— A set of hyperlinks defines a “network” of elements that must be
modified as a group, even though there are no source-code dependencies
among them. A hyperlink connects a source file element that defines
run-time error messages to a document file element that contains a user
manual's “Error Messages Appendix”.
- Merge arrows — ClearCase itself uses a hyperlink to indicate that two versions of an element have had their contents merged.
A hyperlink is an instance of a hyperlink type object (Figure 3-6). Each hyperlink is also a VOB object in its own right, with a unique hyperlink-ID; certain ClearCase commands accept names of hyperlinks in much the same way as they accept file system pathnames:
% cleartool describe util.c (describe file system object) version "util.c@@/main/4" created 10-Dec-93.18:29:11 by (jjp.users@phobos) element type: text_file predecessor version: /main/3 Labels: REL3 % cleartool describe Merge@277 (describe hyperlink object) hyperlink "Merge@277@/usr/hw" created 10-Dec-93.17:50:54 by akp.dvt@neptune Merge@277@/usr/hw /usr/hw/src/util.c@@/main/rel2_bugfix/1 -> /usr/hw/src/util.c@@/main/3 |
A trigger is a “monitor” that tracks development work. When a user-specified ClearCase operation is performed, the trigger fires automatically, executing one or more user-specified trigger actions.
Triggers can help document the development process, improve
communications within the development group, and implement
process-management policies. For example, a trigger might:
A trigger is an instance of a trigger type object. Triggers can be placed on several kinds of objects:
A trigger can be fine-tuned, so that it fires only on
certain ClearCase operations, or when certain kinds of meta-data are
involved. For more on the design and use of triggers, see Chapter 6, “ClearCase Process Control.”
- send mail to a development manager and/or technical writer when a new version of file element cmd_parser.c is created
- send mail to all users when any header (.h) file is modified
- send mail to a project manager when a new branch is created in any element within directory tree /vobs/vega
- attach an attribute to a new version of any source file, indicating the ECO number of the project for which the change was made
- perform a lint(1) check (and require that it succeed) before allowing checkin of a file of type c_source
- require that any new branch type created by a user include the user's login name
- Individual elements — A trigger attached to an element fires each time a ClearCase command operates on the element.
- All elements — A global trigger type is implicitly attached to all the elements in a VOB, both current and future.
- Individual type objects — A trigger attached to a type object
fires whenever the object is used or modified. For example, attaching a
version label to any version of any element would fire a trigger that
is attached to the corresponding label type.
Elements and branches were introduced in the discussion of ClearCase version-control, in Chapter 3, “ClearCase Meta-Data.” There, we stated that “each element has an element type”. Now, we can refine that statement:
That is, a (predefined or
user-defined) element type object must first exist; then, users can
create one or more element objects as instances of the type. Similarly,
each branch is a VOB object, created as an instance of an existing branch type object.
Thus, elements and branches are implemented in the VOB database as instances of type objects, in exactly the same way as version labels, attributes, hyperlinks, and triggers.
“each element is an instance of an element type” |
Thus, elements and branches are implemented in the VOB database as instances of type objects, in exactly the same way as version labels, attributes, hyperlinks, and triggers.
Many ClearCase commands automatically chronicle their work by writing records to one or more VOB databases. Users can examine these records to determine what development work has taken place. clearmake, the ClearCase build utility, implements a build-avoidance scheme that uses records created by previous builds.
Each ClearCase command that makes a change in a VOB creates an event record
that describes the change, including “who, what, when, and where”
information. The event record is permanently stored in the VOB
database, and is logically associated with the particular VOB object
that was changed by the command.
For example, when the checkin command creates a new version, it also writes a create version event record to the VOB-fmt database:
ClearCase includes a simple
report-writing facility, which can be used to extract certain
information from a selected set of event records. For example, the
following report interleaves information drawn from the event records
of a set of elements specified with a wildcard (cmd_*.c), using a
custom format (-fmt option):
For example, when the checkin command creates a new version, it also writes a create version event record to the VOB-fmt database:
27-Jul.15:11 akp create version "tb004.doc@@/main/45" "gordon's corrections" |
% cleartool lshistory -fmt "%Sd %e %n\n" cmd_*.c 24-Mar-94 checkout version cmd_protect.c 24-Mar-94 create version cmd_utl.c@@/main/multisite_v1/5 24-Mar-94 checkout version cmd_list.c 24-Mar-94 create version cmd_list.c@@/main/ibm_port/0 24-Mar-94 create branch cmd_list.c@@/main/ibm_port 23-Mar-94 destroy sub-branch "david_work" of branch cmd_pool.c@@/main 22-Mar-94 create version cmd_registry.c@@/main/16 22-Mar-94 create version cmd_view.c@@/main/138 22-Mar-94 create version cmd_utl.c@@/main/multisite_v1/4 22-Mar-94 create version cmd_utl.c@@/main/112 22-Mar-94 checkout version cmd_utl.c 21-Mar-94 create version cmd_pool.c@@/main/30 21-Mar-94 create version cmd_annotate.c@@/main/17 18-Mar-94 create version cmd_utl.c@@/main/multisite_v1/3 18-Mar-94 create version cmd_utl.c@@/main/111 17-Mar-94 create version cmd_pool.c@@/main/29 16-Mar-94 create version cmd_view.c@@/main/137 16-Mar-94 create version cmd_findmerge.c@@/main/23 16-Mar-94 create version cmd_findmerge.c@@/main/22 16-Mar-94 create version cmd_find.c@@/main/38 14-Mar-94 create version cmd_registry.c@@/main/15 14-Mar-94 create version cmd_findmerge.c@@/main/21 14-Mar-94 destroy sub-branch "akp_tmp" of branch cmd_view.c@@/main 14-Mar-94 create version cmd_registry.c@@/main/akp_tmp/1 11-Mar-94 create version cmd_findmerge.c@@/main/20 |
When the ClearCase build utility clearmake executes a build script, it creates a configuration record (CR)
— the “bill of materials” for that particular execution of the build
script. Like an event record, a CR contains “who, what, when, and
where” information. It also shows how the file was built, by listing
versions of source elements used, build options, makefile macros, the
build script, and more. The CR is logically associated with the file(s)
created by the build script, which are termed derived objects (DOs).
ClearCase includes tools for displaying and comparing CRs, through their associated DOs:
For a full description of configuration records and derived objects, see Chapter 5, “Building Software with ClearCase.”
ClearCase includes tools for displaying and comparing CRs, through their associated DOs:
% cleartool catcr hello.o Target hello.o built on host "neptune" by akp.user Reference Time 19-Nov-93.19:30:12, this audit started 19-Nov-93.19:30:13 View was neptune:/home/akp/akp.vws Initial working directory was neptune:/usr/src ---------------------------- MFS objects: ---------------------------- /usr/src/hello.c@@/main/4 <19-Nov-93.19:30:05> /usr/src/hello.h@@/main/2 <19-Nov-93.19:30:07> /usr/src/hello.o@@19-Mov.19:30.364 ---------------------------- Build Script: ---------------------------- cc -c hello.c ---------------------------- |
Chapter 2, “Version Control - ClearCase VOBs” introduced extended naming, a method for accessing version-controlled data. ClearCase also has a more general query
facility, which locates objects using their associated meta-data.
Queries can be used in many different contexts to locate one or more
elements, branches, or versions. For example:
Following are some examples of ClearCase queries. Note
that queries can involve both ClearCase-generated and user-defined
meta-data:
locates versions that were created by user akp
locates versions that were created recently by user drp
locates versions that have been labeled either REL1 or REL1.01
locates elements for which a merge has been performed, incorporating data from the version labeled REL3 into a version on the rel2_bugfix branch. This operation is recorded in the VOB database by a hyperlink of type Merge.
locates versions to which the BenchMk attribute has been attached with a value less than 45, and to which a trigger named bench_trigger has not been attached.
- A view is typically configured in terms of particular branch names and version labels.
- A quality-assurance engineer might use queries to track source
versions that have achieved a particular level of coding excellence, as
indicated by the value of their CodeQuality attribute.
- A user might use a query on CoordinateWith hyperlinks to determine which elements in the current source tree must be kept synchronized with elements in another tree.
created_by(akp) |
created_by(drp) && created_since(yesterday) |
lbtype(REL1) || lbtype(REL1.01) |
merge(REL3, /main/rel2_bugfix) |
BenchMk<45 && (! trtype(bench_trigger)) |
| Prev | Table of Contents | Next |
| Chapter 2. Version Control - ClearCase VOBs | Chapter 4. ClearCase Views |
No comments:
Post a Comment