About working on branches in base VersionVault

Your organizational policies may dictate that each development project use its own branch to isolate its changes from other development projects. To adhere to this policy, each member of a project team uses a view whose config spec specifies this information:

The versions to select in a specific branch of the development project.
A special auto-make-branch rule. When this view checks out a version, the auto-make-branch rule creates the branch of the development project (if it does not already exist).
For example, each member of the project team that is optimizing the database schema uses a view that selects versions on the db_optimize branch and creates new versions on that branch.

As the figures below illustrate, some or all source files for the project have at least one version on the specified branch.

On the UNIX® system or Linux®

On the Windows® system

$A VOB contains four elements: prog.c, util.h, msg.cat, lib.c. Each element has a main branch with two or more versions. Another branch, pat_usability, is connected to one version in the main branch of each of the following elements: prog.c; util.h; and msg.cat. In elements prog.c, util.h, and msg.cat, the latest version on the pat_usability branch is highlighted. In lib.c the latest version on the main branch is highlighted. The following load rules are listed: load guivob\prog.c; load guivob\util.h; load guivob\msg.cat; load guivob\lib.c. The following version-selection rules are listed: element * \main\pat_usability\LATEST and element * \main\LATEST -mkbranch pat_usability.$

If an element does not have a version on the specified branch, other rules in the config spec select a version of the element. In the illustration, because lib.c does not have a version on the pat_usability branch, the view selects the version on the main branch.

For more information about branches, see the Help and the mkbranch reference page in the VersionVault Command Reference.