Branching Overview

Branching views serve many purposes. For example, you can create a branching view to:

• Meet different needs from those of your main line of development. For example, you might create a maintenance release or a custom version of your product, branched from a prior commercial release.
• Start development on the next release of your product by using some or all of the files from the previous release.
• 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.

Only folders, files, and change requests can branch, although not every folder or every item in a branching view must branch. Requirements, tasks, and topics never branch.

Until an item branches, the corresponding items in both views remain identical. After an item branches, they are no longer identical, and the revision number indicates the new branch. The only way to make the items identical again is to manually merge them by comparing and merging views. After branching occurs, StarTeam no longer sends updates to nor applies updates from the corresponding item in the parent view.

For reasons of safety, deletions made in the parent view are not propagated to the child view and vice versa. If you want to delete a folder or item from all related views, you have to delete it manually from each of those views.

Also, a move is considered a copy operation followed by a delete operation. Consequently, the view in which the move was made has one copy of a folder or item in the new location, while the related views have two copies of the folder or item, one in the original location and one in the new location.