Overview of Views

When you create a new project, the server creates an initial or root view of that project with only the "File" type pre-selected as a default for new views. Users can still change the project properties after the project is created, and they can change the item types included for any given new view. However, if the user changes nothing, by default new views will only include files when they are created.

This initial view, which has the same name as the project, consists of the root folder, to which you will add child folders, files, and eventually, more. It is always read/write. The root view is ideal for collaborative development. because it is dynamic, showing all items in the project as they change.

To accommodate both user and project needs, however, the application enables you to create additional views of a project based on this view. These additional views, called child views, may contain some or all of the contents of the original view and may behave differently. For example, you might use child views to:

Implement the same folder hierarchy for multiple releases of a product. If the root view is for current development, you maintain the folder hierarchy there and create new child views for each release at about the time that it ships. Maintenance would be done in the child view.
Limit the portion of the project that certain team members see. Developers might need to see only the project's source code folder and its child folders; marketing personnel might need to see only the marketing folder and its child folders; and so on. Each of these views can have a different folder as its root.
Support branching and parallel development. By branching files and other data in a new view, your organization can start to work on the 2.0 version of a product without hampering the creation of service packs for the 1.0 version.

Views represent configurations of items and support different development baselines of the same code base. It is common practice to promote changes from one release's maintenance view to the root view where the next release is being created. Views can be reconfigured to show items as they existed at an earlier point in time, or based on a view label or associated promotion state. Rollback views are read-only, as they show a precise state of the items and no longer permit changes.

Understanding Branching Views

A branching view is a view that permits branching—that is, the folders and other items in the view can branch or separate from the corresponding items in the parent.

Branching views serve many purposes; you can create a branching view to meet different needs from those of your main line of development. For example, you might create a branching view for a maintenance release or a custom version of your product. A branching view can also be used to keep an area of your project private until it is completed and tested. Then you can merge your changes into the main line of development when and where necessary.

A branching view should use a different working folder than that of its parent view. Using the same working folder for both views is not only confusing but can create status problems.

Item Branching Behavior

Given the appropriate settings, folders, files, and change requests in a child view can be branched, that is, can be separated from the corresponding item in the parent view. Folders and change requests branch when their properties change, while files branch when either their contents or their properties change (Requirements, tasks, and topics can never branch).

For each item, branching occurs a maximum of one time per view. For example, if a new item is added to the root view, its first revision has the dot notation 1.0. Subsequent revisions become 1.1, 1.2, and 1.3. Suppose this item is included in two child views created from the root view and that both of the child views are branching views. In one child view, if a new revision is made to the item, the item branches. This separation from its "parent" item in the root view is indicated by an addition of two numbers to the dot notation. If the parent item was 1.3, the child item becomes 1.3.1.0. The child item's next revision becomes 1.3.1.1.

Now, suppose the corresponding item in the second child view is changed. Its dot notation must also change. Because 1.3.1.0 already exists, the separation of this item from its parent item gets the dot notation 1.3.2.0. This child item's next revision becomes 1.3.2.1.

The original item in the root view has the history: 1.0>1.1>1.2>1.3. The next revision will be 1.4. The item in one child view has the history: 1.0>1.1>1.2>1.3>1.3.1.0>1.3.1.1. The next revision will be 1.3.1.2. The item in the other child view has the history: 1.0>1.1>1.2>1.3>1.3.2.0>1.3.2.1. The next revision will be 1.3.2.2.

Whether or not a folder, file, or change request has the ability to branch depends upon its behavior settings.

If the Branch on Change check box for an item is enabled and selected, the item can branch.
If the Branch on Change check box for an item is enabled but not selected, the item cannot branch, but its behavior can be changed.
If the Branch on Change check box for an item is disabled, the item has either already branched or its location is where it was added to StarTeam.
If the Branch on Change check box for a folder is enabled but not selected, new items cannot be added. If you attempt to do so, an error message will appear, stating that the folder is read-only.

Note: Changing a folder’s branching behavior does not affect the behavior of items in the folder. Items in a folder have their own branching behavior.

Items in Both the Parent and the Branching View

Depending on the folders included in the new branching view, certain items from the parent view appear in the new branching view. However, these “inherited” items will have no labels, as neither view labels nor revision labels move from view to view.

As a result, the workflow for change requests is affected in the following ways:

If the Last Build Tested and the Addressed In Build fields in a change request have no values when the change request branches, their workflow is specific to the new view only.
If the Last Build Tested and the Addressed In Build fields in a change request have build labels as their values (i.e., these fields are not empty or do not contain the value Next Build) when the change request branches, the branched change request retains those values. In the new view, these values can be changed, but only to the names of build labels that exist in the new view.
If the Addressed In Build field contains the value Next Build when the change request branches, the Next Build value is replaced by the name of the next build label created in the parent view, not the next build label created in the new view.