Defining Project Views

Task branches are short-lived, typically involve a small percentage of files, and are merged into their parent branch after the task is completed. Task branches promote accountability by leaving a permanent audit trail that associates a set of changes with a particular task; they also make it easy to identify the task artifacts, such as views and derived objects, that can be removed when they are no longer needed. If individual tasks don’t require changes to the same files, it is easy to merge a task branch to its parent.

Private development branches are useful when a group of developers need to make a more comprehensive set of changes on a common code base. By branching as much of the main branch as needed, developers can work in isolation as long as necessary. Merging back to the main branch can be simplified if, before merging, each developer merges the main branch to the private branch to resolve any differences there before checking in the changed files.

Integration branches provide a buffer between private development branches and the main branch and can be useful if you delegate the integration task to one person, rather than making developers responsible for integrating their own work.

Branch Names

It’s a good idea to establish naming conventions that indicate the work the branch contains. For example, rel2.1_main is the branch on which all code for Release 2.1 ultimately resides,

rel2.1_feature_abc contains changes specific to the ABC feature, and rel2.1_bl2 is the second stable baseline of Release 2.1 code. (If necessary, branch names can be much longer and more descriptive, but long branch names can crowd a version tree display.)

NOTE: Make sure that you do not create a branch type with the same name as a label type. This can cause problems when config specs use labels in version selectors. For example, make all branch names lowercase, and make all label names uppercase.

Branches and ClearCase MultiSite

Branches are particularly important when your team works in VOBs that have been replicated to other sites with the ClearCase MultiSite product. Developers at different sites work on different branches of an element. This scheme prevents collisions—for example, developers at two sites creating version /main/17 of the same element. In some cases, versions of files cannot or should not be merged, and developers at different sites must share branches. For more information, see Policy: Certain Branches Are Shared Among MultiSite Sites on page 138.

Creating Shared Views and Standard Config Specs

As a project manager, you want to control the config specs that determine how branches are created when developers check out files. There are several ways to handle this task:

➤ Create a config spec template that each developer must use. Developers can either paste the template into their individual config specs or use the ClearCase include file facility to get the config spec from a common source.

➤ Create a view that developers will share. This is usually a good way to provide an integration view for developers to use when they check in work that has evolved in isolation on a private branch.

NOTE: Working in a single shared view is not recommended because doing so can degrade system performance.

➤ Use the ClearCase View Profiles mechanism to configure views that the project team will use. The View Profile tools promote a specific model for the effective use of ClearCase.

Project teams that adhere to this model can take advantage of several areas of automated support, significantly simplifying their ability to exploit some of the more advanced features of ClearCase. For more information on View Profiles, see the online help.

➤ To ensure that all team members configure their views the same way, you can create files that contain standard config specs. For example:

➣ \\vulcan\c\public\c_specs\abc contains the ABC team’s config spec

➣ \\vulcan\c\public\c_specs\xyz contains the XYZ team’s config spec

Store these config spec files in a standard directory outside a VOB, to ensure that all developers get the same version.

Recommendations for View Names

You may want to establish naming conventions for views for the same reason that you do for branches: it is easier to associate a view with the task it is used for. The ClearCase view-creation tools suggest appropriate view names, but you may want to use something different. For

8.2 Implementing Development Policies

To enforce development policies, you can create ClearCase metadata to preserve information about the status of versions. To monitor the progress of the project, you can generate a variety of reports from this data and from the information that ClearCase captures in event records.

Using Labels

A label is a user-defined name that can be attached to a version. Labels are a powerful tool for project managers and system integrators. By applying labels to groups of elements, you can define and preserve the relationship of a set of file and directory versions to each other at a given point in the development lifecycle. For example, you can apply labels to these versions:

➤ All versions considered stable after integration and testing. Use this baseline label as the foundation for new work.

➤ All versions that are partially stable or contain some usable subset of functionality. Use this checkpoint label for intermediate testing or as a point to which development can be rolled back in the event that subsequent changes result in regressions or instability.

➤ All versions that contain changes to implement a particular feature or that are part of a patch release.

Using Attributes, Hyperlinks, Triggers, and Locks

Attributes are name/value pairs that allow you to capture information about the state of a version from various perspectives. For example, you can attach an attribute named

CommentDensity to each version of a source file, to indicate how well the code is commented.

Each such attribute can have the value unacceptable, low, medium, or high.

Hyperlinks allow you identify and preserve relationships between elements in one or more VOBs. This capability can be used to address process-control needs, such as requirements tracing, by allowing you to link a source file to a requirements document.

Triggers allow you to control the behavior of cleartool commands and ClearCase operations by arranging for a specific program or executable script to run before or after the command executes. Virtually any operation that modifies an element can fire a trigger. Special environment

variables make the relevant information available to the script or program that implements the procedure.

Preoperation triggers fire before the designated ClearCase command is executed. A preoperation trigger on checkin can prompt the developer to add an appropriate comment. Postoperation triggers fire after a command has exited and can take advantage of the command’s exit status.

For example, a postoperation trigger on the checkin command can send an e-mail message to the QA department, indicating that a particular developer modified a particular element.

Triggers can also automate a variety of process management functions. For example:

➤ Applying attributes or attaching labels to objects when they are modified

➤ Logging information that is not included in the ClearCase event records

➤ Initiating a build and/or source code analysis whenever particular objects are modified For more information on these mechanisms, see Chapter 10, Implementing Project Development Policies.

A lock on an element or directory prevents all developers (except those included on an exception list) from modifying it. Locks are useful for implementing temporary restrictions. For example, during an integration period, a lock on a single object—the main branch type—prevents all users who are not on the integration team from making any changes.

The effect of a lock can be small or large. A lock can prevent any new development on a particular branch of a particular element; another lock can apply to the entire VOB, preventing developers from creating any new element of type compressed_file or using the version label RLS_1.3.

Locks can also be used to retire names, views, and VOBs that are no longer used. For this purpose, the locked objects can be tagged as obsolete, effectively making them invisible to most commands.

Global Types

The ClearCase global type facility makes it easy for you to ensure that the branch, label, attribute, hyperlink, and element types they need are present in all VOBs your project uses. The manual

Generating Reports

ClearCase creates and stores an event record each time an element is modified or merged. Many ClearCase commands include selection and filtering options that you can use to create reports based on these records. The scope of such reports can cover a single element, for a set of objects, or for entire VOBs.

Chapter 10, Implementing Project Development Policies, provides more detail on using event