Content deleted Content added
fmt; ch cat |
|||
Line 1:
'''Rational ClearCase''' is a [[computer software|software]] tool for [[revision control]] ([[configuration management]], [[SCM]] etc) of [[source code]] and other software development assets. It originally derived from a product of [[Apollo Computers]]: ''DSEE'' ([[Apollo Domain|Domain]] Software Engineering Environment), which was ported to Unix and further developed by Atria Software after [[Hewlett-Packard]] bought Apollo. Atria later merged with Pure Software to form PureAtria. That firm merged with [[Rational Software]], which was purchased by [[IBM]]. IBM continues to develop and market ClearCase. ClearCase forms the base of version control for many large and medium sized businesses and can handle projects with hundreds or thousands of developers, but the price is quite steep for smaller companies.
==
Objects under version control in ClearCase are stored with their histories in repositories called '''VOBs''' ('''v'''ersioned '''o'''bject '''b'''ase). ClearCase's novelty was in its versioned file system (called MVFS: '''M'''ulti'''v'''ersion '''F'''ile '''S'''ystem), which can be used to mount VOBs as a virtual file system through a ''dynamic view'', selecting a consistent set of versions and allowing for the production of [[Derived Object|derived objects]]. The dynamic view allows this to map to a [[Software Configuration]]. This was a departure from the ''repository''/''sandbox'' model, allowing for the early management of artifacts (before they are being checked in, and not limited to these first order configuration items).
Line 11 ⟶ 10:
Each developer typically has one or several views at his disposal. It is sometimes practical to share views between developers, but sharing branches is usually used instead. Having a branch hierarchy is often useful, so an entire development project shares a common development branch, while a smaller team shares a sub-branch, and each developer has his or her private branch. Whenever some change is deemed stable enough for a larger group, it can be merged to the parent branch.
==
Each view is controlled by its associated ''configuration specification''. This is a text file that specifies what elements (files or directories) should be visible in a view, and which versions of these elements. When deciding which version, if any, of an element should be visible, ClearCase traverses the configuration specification line-by-line until a match is found. A sample configuration specification could look like this:
Line 40 ⟶ 38:
A configuration specification can also reference other configuration specifications using the 'include' statement.
==
Another originality of ClearCase is its MultiSite extension. In this model, there is no real master database, but instead peer ''replicas'', kept in-step in an asynchronous way (with close to no penalty to end-users).
Since replicas are kept in sync in an asynchronous way, ClearCase must keep track of access so that multiple teams do not perform conflicting operations. The paradigm of mastership allows this. Specific data or metadata within a VOB have a property which specifies what particular replica is allowed to modify them. Thus, a VOB object or piece of metadata can only be manipulated by one replica at a time. MultiSite also has the ability to change this property so that different teams can change the mastership of VOB data. This can be done by changing the mastership manually from a "giving" site or by a request for mastership from a "receiving" site.
==
In the recent years, a [[UCM]] ('''U'''nified '''C'''hange '''M'''anagement) extension has been developed, supporting a more traditional model.
==
* '''Build Avoidance''': Use of MVFS (Multiversion File System) allows derived objects built in one dynamic view to be automatically "copied over" to another dynamic view requiring "exactly the same" derived object. Two derived objects are deemed to be "exactly same" if they have the same ''configuration record'' (ClearCase terminology, also called ''bill of materials''). Shared derived objects will be physically present on the VOB server, and not in the views that reference them. The process of "copying over" is called ''winking in'' in ClearCase terminology.
* '''Unix/Windows Interoperability:''' VOBs hosted on *nix (Solaris, Linux, AIX, HP-UX, Irix primarily) servers can be accessed from views hosted on Windows clients. VOBs hosted on Windows servers can only be accessed by Unix clients with snapshot views. .
Line 64 ⟶ 59:
[[Category:IBM software|ClearCase]]
[[Category:Software engineering]]
[[Category:
| |||