Proper Use of Views

Regardless of view type, below are some general do’s and don’ts to consider when creating and managing views:

• Try to ensure that items in the main view refer to the main (1.n) branches of its artifacts. Also, be careful not to delete the 1.n branch of an artifact unless it has truly achieved end-of-life.
• Leaf-most views should be considered disposable. Eventually, when a view’s corresponding development activity is finished or its corresponding maintenance release is no longer supported, it should be deleted. This is important to prevent projects from growing unbounded, and it keeps the project structure uncluttered and easy to navigate. Deleting leaf views provides the Server Administration “purge” process with the maximum opportunity to actually shrink the database and vault by removing unneeded data.
• Three or four view levels in a project are normal. If you find your project has more than that, you might not be following best practices for views. For example, you may be making the mistake of performing new development work directly in the main view, forcing other active views to keep spawning child views. Or, you may be neglecting to promote the latest and greatest changes to the main view.
• Don’t use branch-none (“floating”) views except in extremely rare cases when you understand exactly how they work.
• You can “refactor” projects that have become too big by moving items in the main view to another project. Old change requests, tasks, and other projects can be moved to an “archive” project so they can still be accessed without cluttering the main view of an active project. If you have a project with numerous modules or applications, a large number of files can cause it to take too long to select “all descendants” in the main view. You can break the project up by creating new projects and moving (not sharing) folders and items corresponding to whole components or applications from the old project to the new projects. Do this when the main view reaches a major milestone such as after a new release. If you want to refactor the project by reorganizing the folder tree, do this before you split up the project. Create view labels before and after you refactor a project so you have markers for what changed.