|
|
This section describes the planning and setup work you need to do before development begins.
If your project is migrating to ClearCase from another version control product or is adopting a configuration and change management plan for the first time, you must populate the VOBs for your project with an initial collection of data (file and directory elements). If your site has a dedicated ClearCase administrator, he or she may be responsible for creating and maintaining VOBs, but not for importing data into them.
The Administrator's Guide for Rational ClearCase and the Administrator's Guide for Rational ClearCase LT include detailed information on these topics.
ClearCase uses branches to enable parallel development. A branch is an object that specifies a linear sequence of versions of an element. Every element has one main branch, which represents the principal line of development, and may have multiple subbranches, each of which represents a separate line of development. For example, a project team can use two branches concurrently: the main branch for new development work and a subbranch to fix a bug. The aggregated main branches of all elements constitutes the main branch of a code base.
Subbranches can have subbranches. For example, a project team designates a subbranch for porting a product to a different platform; the team then decides to create a bug-fixing subbranch off that porting subbranch. ClearCase allows you to create complex branch hierarchies. Figure 1 here illustrates a multilevel branching hierarchy. As a project manager in such an environment, you need to ensure that developers are working on the correct branches. To do that, you must tell them which rules to include in their config specs so that their views access the appropriate set of versions.
Chapter 11, Defining Project Views, describes config specs and branches in detail. Before you read it, a little background on branching strategies may be helpful.
Branching policy is influenced by the development objectives of the project and provides a mechanism to control the evolution of the code base. There are as many variations of branching policy as organizations that use ClearCase. But there are also similarities that reflect common adherence to best practices. Some of the more common branch types and uses are presented here.
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.
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.
PRODUCT NOTE: Rational ClearCase LT does not support 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 Certain Branches Are Shared Among MultiSite Sites.
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.
PRODUCT NOTE: Rational ClearCase LT does not support view profiles.
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.
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 example, you can require all view names (called view-tags) to include the owner's name and the task (bill_V4.0_bugfix) or the name of the computer hosting the view (platinum_V4.0_int).
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
