Editing IBM DevOps Code ClearCase (section)

== Views ==

A distinguishing feature of ClearCase is the [[MultiVersion File System]] (MVFS), a proprietary [[networked filesystem]] which can mount VOBs as a virtual file system through a dynamic view, selecting a consistent set of versions and enabling the production of [[Derived Object|derived objects]]. This was a departure from the repository-and-sandbox model because it enabled the early management of artifacts (that is, before they are checked in) and was not limited to the management of these first-order configuration items.

ClearCase also supports snapshot views, which are copies of repository data. As opposed to dynamic views, snapshot views are maintained on a local (OS-specific) file system and do not require network access. Instead, a snapshot view stores a copy of the VOB data locally on the user's computer. Snapshot views can be used while disconnected from the network and later synchronized with the VOB when a connection is reestablished. This mode of operation is similar to that of CVS (Concurrent Versions System) software.

The dynamic and snapshot view types are supported by the ClearCase local client (CCLC). The ClearCase remote client (CCRC) supports analogous view types: the automatic view and the web view. Both are copy-based, but the automatic view uses the MVFS to support local, shareable pools of VOB objects.

From the perspective of the client computer, a ClearCase view appears to be just another file system. New files and directories created in a ClearCase view are referred as "view-private" to indicate that they are specific to the view and not version-controlled. This feature allows build systems to operate on the same file system structure as the source code and ensures that each developer can build independently of one other. At any time, a view-private object can be added to source control and become a versioned object, rendering it visible to other users.

Developers typically have one or more views at their disposal. It is sometimes practical to share views between developers, but sharing branches is the more common practice. A branch hierarchy is often useful: an entire development project can share a common development branch, while a smaller team can share a sub-branch, with each developer having his or her own private branch. Whenever a change on a branch is deemed stable enough, it can be merged to the parent branch.