View Types
As shown, there are six concrete view types. Aside from the special root view type and one non-derived view type, the rest are derived view types, which subdivide into reference and variant types, each of which have two concrete types.
The abstract and concrete view types are described below.
- Root View
- A root view is the “main” view automatically created for each project. Initially, it receives the same name as the project, but you can change it. (It is often renamed “Main” to emphasize its role.) When first created, the root view has only a root folder whose name matches the view. It is the only view type that has no parent, it forms the top of the project’s view hierarchy.
- Non-derived View
- This is also called a blank view. Like the main view, it initially has no items except for a root folder. Although a non-derived view has a parent view, it is not derived from that parent, which means it does not inherit the parent view’s items. You can add new items to it, or you can share items from other views into it. A non-derived view can be used for non-lifecycle activities, acting like a “scratch pad” that you build up one item at a time.
- Derived View
- A derived view begins life as a subset or an exact copy of its parent view. One of the parent view’s folders (often the root folder) is chosen as the root folder of the derived view; hence the derived view starts as a window into the artifacts at which it is rooted. What you can do with the artifacts in a derived view depend on whether it is a variant or reference view.
- Reference View
- A reference view is a derived view that is a pure subset of its parent view. A reference view does not have its own items;
it uses the same items as its parent view. Consequently, updates made to a reference view (if allowed) are applied to the
same items used by the parent view. This also means that reference views never have their own artifact branches; hence reference
views are also called
non-branching views. Reference views also do not have their own view labels, they share the same labels as their parents. Reference views are
considered lightweight since they do not have their own items. A reference view can be updateable or read-only.
- Updateable Reference View
- An updateable reference view is a pure subset of its parent view with no added restrictions. If an item is updateable in the parent view, it is updateable in the reference view as well. Since the two views share the same items, changes in either view are immediately visible in both views. An updateable reference view is useful for exposing a portion of another view for security purposes. Instead of adding folder- and/or item-level security rights to the parent view, adding view-level security rights to an updateable reference child view is often easier to manage.
- Read-only Reference View
- A read-only reference view is a subset of items from the parent view that cannot be modified through the child view. A child view can float to the tip configuration of the parent view. In this case, it immediately reflects any changes made in the parent view to items it can see. Alternatively, a read-only reference view can be pinned to a specific configuration of the parent view: a timestamp, view label, or promotion state. A pinned read-only reference view reflects the state of the parent view (subset) as of that configuration. Once the child view is created, you can’t change the configuration on which it is based. However, in the case of labels and promotion states, the child view will follow changes made to those objects. For example, if new items or different revisions are attached to the label or promotion state in the parent view, the child view will immediately reflect that change. Floating and pinned read-only reference views are useful when you want to subset a view and ensure read-only access, for example with applications such as build scripts.
- Variant View
- Unlike reference views, a variant view is not a pure subset of its parent view. Although a variant view may initially be created
as an exact copy or subset of its parent view, it has its own items. In fact, when a variant view is first created, the parent
view’s items (or subset thereof) are shared (copied) to the child view, initially referencing the same artifacts. When new
items are added to the child view, they may not be automatically added to the parent view depending on the containing folder’s
configuration. Furthermore, since it has its own items, the variant view’s items may be independently configured, which means
they could branch. Consequently, variant views are also called
branching views. Whether or not a variant view’s items are initially marked branch-on-change (BOC) is the major difference between the two
variant view subtypes.
- Branch-none View
- If a variant view’s items are initially configured with BOC set to “false”, it is referred to as a branch-none view. It acts a bit like a reference view, except that it doesn’t share labels with its parent. If the child view’s items are created with a pinned configuration, they will be read-only. If the item configurations float, updates through those items will float to the parent. This is why a branch-none view is sometimes called a “floating view”. However, because the child view has its own items, “moves” in the child will not propagate to the parent view. Because of the discrepancy between the propagation behavior of moves versus other updates, branch-none views can be very confusing. It is possible to create branch-none views and hand-tweak item configuration and branch-on-change, but this approach has proven tricky at best and sometimes disastrous. Consequently, we recommend against using branch-none views.
- Branch-all View
- Branch-all variant views are the most commonly-used views. A branch-all view begins life as a copy of its parent view (or subset thereof), with branch-on-change set to “true” for all items (that point to branchable artifact types). A branch-all view’s item can be configured to float, causing changes in the parent view to float to the child view. However, branch-all views are far more useful when all items are configured to a specific timestamp or view label.
Of the six StarTeam view types, you will use main views and branch-all views with configured items (not floating items) the most. As detailed in the next section, each project will have only one main view, but you will use branch-all views to support both new development and maintenance activities. Reference views are occasionally used as a way to expose a read-only or updateable subset of its parent while simplifying security management. Blank views are rarely used, and branch-none views are not recommended.