The main view, also known as the root view, should contain the latest, approved revisions for the whole project. By latest, we mean that the main view should match your latest changes, ready for the next release. By approved, we mean that it should contain revisions that have undergone whatever verification checks your process requires: a complete build, unit testing, integration testing, etc. By whole project, we mean that it should not be a subset of the project’s modules. In short, your main view should contain the latest, complete, production work, ready to be seen and used by everyone.
Implicit in this recommendation is that the main view should always be clean. That means it should be buildable and able to pass most if not all tests. Experience has shown that you will avoid many headaches by keeping your main view clean. To do this, all except for the simplest changes should be made in other views where they can be tested and fine-tuned until they’re ready to be propagated to the main view. Once a new or modified revision has passed the point of no return—you’re sure you won’t change your mind—only then should it appear in the main view.
There is a subtle but important interaction between the main views and “share trees” you should be aware of. In general, the main view should contain the main (1.n) branch of each artifact. This happens automatically when you add a new artifact in the main view. StarTeam first creates a new 1.0 artifact and then connects it to the view and parent folder with a new item. But suppose you create a new artifact in a child view and then share the item “up” to the main view. Since the child view item was created first, it will be the “root share”, and the main view item will receive a “child share” item (initially pointing to the same artifact). In other words, the item share tree will point in the opposite direction as the views. You probably won’t notice a problem until you modify the item in the main view, causing it to branch, thereby pointing to a non-main branch (e.g., 1.n.1.m). In future attempts to propagate changes between the two views, you’ll find that it gets harder to propagate changes correctly because the share tree is backwards. For example, “rebase” operations won’t work correctly. What can you do about this? The solution is to use the view compare/merge (VCM) facility to promote new items to the main view. VCM understands the share tree issue and propagates new items using an operation called reverse share.