Content deleted Content added
Correction on mounting of VOBs. Brief explanation of VOBs. |
No edit summary |
||
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.
== Views ==
Line 6:
Alternatively, ClearCase supports ''snapshot views'' which are just copies of a directory tree spanning one or several VOBs. Snapshot views do not use a virtual file system to provide access to VOB data. 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 resynchronized to the VOB when a connection is reestablished. This mode of operation is similar to how the widely-used [[Concurrent Versions System|CVS]] (Concurrent Versions System) software works.
From the perspective of software on the client computer, a view appears as just another file system. If a file is created in a view by normal OS means (copying or saving from an editor for instance), then ClearCase will create this file as a "view local" file. It will not be visible in any other view. This allows build systems to operate in the same directory structure as the source code, and ensures that each developer can build completely independently of each other (though if the view is a dynamic one then the normal overhead associated with accessing files over an NFS link applies). A view-local file (or directory for that matter) can be converted into a versioned element at any time, making it visible to other developers.
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.
== Configuration specifications ==
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:
<pre>
# Show all elements that are checked out to this view, regardless any other rules.
element * CHECKEDOUT
# If an element has a version on the 'module2_dev_branch', then this shall be the visible version in this view.
element * module2_dev_branch
# For all files named 'somefile', regardless of ___location, always show the latest version on the main branch.
element .../somefile /main/LATEST
# Use a specific version of a specific file. Note: This rule must appear before the next rule to have any effect!
element /vobs/project1/module1/a_header.h /main/proj_dev_branch/my_dev_branch1/14
# Show all elements labeled with the tag 'PROJ1_MOD2_LABEL_1' under the 'project1/module1' path.
# Furthermore, don't allow any checkouts in this path.
element /vobs/project1/module1/... PROJ1_MOD2_LABEL_1 --nocheckout
# Show the 'ANOTHER_LABEL' version of all elements under the 'project1/module2' path.
# If an element is checked out, then branch that element from the currently visible version,
# and add it to the 'module2_dev_branch' branch.
element /vobs/project1/module2/... ANOTHER_LABEL --mkbranch module2_dev_branch
</pre>
A configuration specification can also reference other configuration specifications using the 'include' statement'
== MultiSite ==
Line 27 ⟶ 60:
*[http://www-106.ibm.com/developerworks/rational/rationaledge/ Rational Edge e-zine]
*[http://www.clearconsulting.co.uk Clear Consulting (UK) Ltd (UK Rational Solution Provider, Consultancy, Training for ClearCase, ClearQuest, MultiSite, UCM) ]
*[http://eclipse-ccase.sourceforge.net Eclipse ClearCase Integration, Open Source]
[[Category:IBM software|ClearCase]]
| |||