11.5 Views for Project Development

The config specs in this section are useful for project development because they enforce various branching policies.

View for New Development on a Branch

You can use this config spec for work to be isolated on branches named major:

In this scheme, all checkouts occur on branches named major (Rule 2).

major branches are created at versions that constitute a consistent baseline: a major release, a minor release, or a set of versions that produces a working version of the application. In this config spec, the baseline is defined by the version label BASELINE_X.

Variation That Uses a Time Rule

Sometimes, other developers check in versions that become visible in your view, but are incompatible with your own work. In such cases, you can continue to work on sources as they existed before those changes were made. For example, Rule 2 in this config spec selects the latest version on the main branch as of 4:00 P.M. on November 12:

Note that this rule has no effect on your own checkouts.

View to Modify an Old Configuration

This config spec allows developers to modify a configuration defined with version labels:

Note the following:

• Elements can be checked out (Rule 1).

• The checkout command creates a branch named r1_fix at the initially selected version (the auto-make-branch clause in Rule 3).

A key aspect of this scheme is that the same branch name, r1_fix, is used in every modified element. The only administrative overhead is the creation of a single branch type, r1_fix, with the mkbrtype command.

This config spec is efficient: two rules (Rules 2 and 3) configure the appropriate versions of all elements:

• For elements that have been modified, this version is the most recent on the r1_fix subbranch (Rule 2).

• For elements that have not been modified, this version is the one labeled R1.0 (Rule 3).

Figure 39 illustrates these elements. The r1_fix branch is a subbranch of the main branch. But Rule 2 handles the more general case, too: the ... wildcard allows the r1_fix branch to occur anywhere in any element's version tree, and at different locations in the version trees of different elements.

Figure 39 Making a Change to an Old Version

Omitting the \main\LATEST Rule

The config spec in View to Modify an Old Configuration omits the standard \main\LATEST rule. This rule is not useful for work with VOBs in which the version label R1.0 does not exist. In addition, it is not useful in situations where new elements are created. If your development policy is to not create new elements during maintenance of an old configuration, the absence of a \main\LATEST rule is appropriate.

To allow creation of new elements during the modification process, add a fourth configuration rule:

When a new element is created with mkelem, the -mkbranch clause in Rule 4 causes the new element to be checked out on the r1_fix branch (which is created automatically). This rule conforms to the scheme of localizing all changes to r1_fix branches.

Variation That Uses a Time Rule

This baseline configuration is defined with a time rule.

View to Implement Multiple-Level Branching

This config spec implements and enforces consistent multiple-level branching.

A view configured with this config spec is appropriate in the following situation:

• All changes from the baseline designated by the BASELINE_X version label must be made on a branch named major.

• Moreover, you are working on a special project, whose changes are to be made on a subbranch of major, named autumn.

Figure 40 shows what happens in such a view when you check out an element that has not been modified since the baseline.

Figure 40 Multiple-Level Auto-Make-Branch

For more on multiple-level branching, see the config_spec and checkout reference pages.

View to Restrict Changes to a Single Directory

This config spec is appropriate for a developer who can make changes in one directory only, \monet\src:

The most recent version of each element is selected (Rules 2 and 3), but Rule 3 prevents checkouts to all elements except those in the directory specified.

Note that Rule 2 matches elements in any directory named src, in any VOB. The pattern \monet\src\* restricts matching to only one VOB.

This config spec can be extended easily with additional rules that allow additional areas of the source tree to be modified.