The Full Wiki

IBM Rational ClearCase: Wikis

Advertisements
  

Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.

Encyclopedia

From Wikipedia, the free encyclopedia

Rational ClearCase is a software tool for revision control (e.g. configuration management, SCM) of source code and other software development assets. It is developed by the Rational Software division of IBM. ClearCase forms the base of version control for many large and medium sized businesses and can handle projects with hundreds or thousands of developers.

ClearCase supports two kinds of use models, UCM, and base ClearCase. UCM provides an out-of-the-box model while base ClearCase provides a basic infrastructure (upon which UCM is built) which allows for more flexibility. Both can be configured to support a wide variety of needs.

ClearCase can run on a number of platforms including AIX, z/OS, Linux, HP-UX, Solaris and Windows.[1] It can handle large binary files, large numbers of files, and large repository sizes. It handles branching, labeling, and versioning of directories.

Contents

History

ClearCase was developed by Atria Software and first released in 1992[2] on Unix and later on Windows. Some of the Atria developers had worked on an earlier system: DSEE (Domain Software Engineering Environment) from Apollo Computer. After Hewlett-Packard bought Apollo Computer in 1989, they left to form Atria.[3][4][5] Atria later merged with Pure Software to form PureAtria.[6] That firm merged with Rational Software, which was purchased by IBM in 2003 [7]. IBM continues to develop and market ClearCase.

Advertisements

DSEE

DSEE introduced many concepts now used in ClearCase. The Apollo Domain file system allowed special handler programs to intervene during file access, and DSEE made use of this to invisibly substitute a versioned copy when a particular file was opened. With the versioning specification resident in the user environment, all accesses to versioned files were redirected, including such mundane accesses as printing, viewing in a generic text editor etc.

DSEE relied heavily on a file which described all the software modules and their dependencies. This file had to be generated manually, which was a major impediment to its use in large systems. However once generated it allowed DSEE to calculate the optimum way to perform a build, re-using all modules that had previously been processed and whose version specifications matched the specifications for the current build.

DSEE also introduced the "version spec" which was then called a "thread". This was a list of possible versions that could be in the user environment, or in a build. The major innovation was using build signatures and software release signatures in the thread. The items in a thread might thus be:

  • Any copies reserved for editing (i.e. checked out)
  • Latest version (usually for developers only)
  • A branched version of a file (a version on an alternate line of development).
  • A labeled version (for developers working on a particular revision level)
  • The version used in build XYZ.
  • The version used in software release x.y.z.

Threads were processed from top to bottom for each file. A developer thread might have "reserved" at the top, followed by a labeled version. For a quick fix to an existing release, the thread would be "reserved", then the release signature.

In the absence of the invisible file redirection of the Apollo Domain file system, Rational ClearCase uses the virtual file system provided by the MVFS feature described below. The "thread" concept corresponds to the dynamic view. Support for derived objects in a view is similar to DSEE's concept.

ClearCase releases

  • Version 7.1 (December 2008) introduced a great many changes and improvements for both the CCRC clients, a new CM Server platform (a generic WebSphere application server platform for ClearQuest), a generic programming model for both CC/CQ, a new multi-site monitoring system and more.
  • Version 7.1.1 (December 2009) introduced a number of new features and improvements including atomic commit.

Views

Objects under version control in ClearCase are stored in repositories called VOBs (Versioned Object Base). A distinguishing feature of ClearCase is a proprietary networked filesystem (MVFS: MultiVersion File System) [8] , 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 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).

Alternatively, ClearCase supports snapshot views which are just copies of repository data specified by a config-spec which spans one or several VOBs. As opposed to dynamic views, snapshot views are maintained on a local (OS-specific) filesystem 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 resynchronized to the VOB when a connection is reestablished. This mode of operation is similar to how the widely-used CVS (Concurrent Versions System) software works.

From the perspective of software on the client computer, a view appears as just another file system. If new data is created in a ClearCase view then ClearCase will refer to the new data (files, directories, ...) as view-private to indicate it is specific to the view being used and not being version controlled (private) by ClearCase. This allows build systems to operate on the same file system structure as the source code, and ensures that each developer can build independently of each other. A view-private object can be added to source control and become a versioned element at any time, making it visible to other users.

Each developer typically has one or several views at their 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

Under base ClearCase, each view is controlled by its associated configuration specification, commonly referred to as a config spec. This is a collection of rules (stored internally in a text file, but compiled to a more efficient form before use) 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 from top to bottom, stopping when a match is found. Earlier rules always take priority over later ones.

A typical configuration specification could look like this:

# 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 the latest 
# version of this branch shall be the visible version in this view.
element * .../module2_dev_branch/LATEST

# 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

# For other files in the 'project1/module1' directory, show versions 
# labeled  'PROJ1_MOD2_LABEL_1'. 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

A configuration specification can also reference other configuration specifications using the 'include' statement.

Under ClearCase UCM these config specs still exist but do not need to be maintained or edited anymore by end-users or administrators.

Features

  • Build auditing: The networked filesystem provided by MVFS allows for build auditing. Builds performed on a dynamic view which use the MVFS are able to monitor and record I/O operations performed during the build process. This allows ClearCase to produce a bill-of-materials which it calls a Configuration Record (CR) for all builds and enable traceability for either Software Configuration Management purposes or as part of a larger Application Lifecycle Management process. Build auditing is performed with command-line tools such as a built-in make tool (omake, clearmake) or by using the clearaudit command which can invoke a separate build tool.
  • VOB (VERSIONED OBJECT BASE): A repository that stores versions of file elements, directory elements, derived objects, and metadata associated with these objects. With MultiSite, a VOB can have multiple replicas, at different sites.
  • Configuration Record: The bill-of-materials artifact produced as the result of build auditing that contains:
    • Build procedure: The method (script, makefile, ...) that invoked the build
    • Inputs: All files (and their specific versions) that were used for a particular build.
    • Outputs: All derived object (DO) files (and any dependent DOs) produced as a result of the build.

The dependency information is stored in a hidden configuration record which can be shown for each derived object. The configuration record can be used to set up another view showing all files that have been read before during the build time. Alternatively, you can use the configuration record to apply a label to the files (and versions) that were read during the build.

  • 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. This feature requires that the clearmake or omake tools are used instead of other build systems.
  • Unix/Windows Interoperability: VOBs hosted on *nix (Solaris, Linux, AIX, HP-UX, IRIX primarily) servers can be accessed with dynamic views, snapshot views, or the new web protocol based client: the CCRC on Windows clients. VOBs hosted on Windows servers can be accessed with snapshot views or CCRC from Unix clients, but not dynamic views due to the Windows server returning file paths with backslashes as the path delimiter. There is a 3rd party patch [9] for Linux to enable dynamic views from Windows VOBs.
  • Integration With Other Products: Other products (originally) from Rational Software, notably ClearQuest and Rational Rose, integrate with ClearCase. ClearCase also integrates with TextPad, Microsoft Visual Studio, Code::Blocks, NetBeans and the Eclipse IDE through a plugin. There are also Emacs[10] and Vim[11] plugins available.

Weaknesses

  • Speed: ClearCase dynamic views are slower than local filesystems, even with good network infrastructure. A benchmark in a study by Perforce shows that many basic tasks take about twice as long to run using a ClearCase dynamic view than Perforce's SCM tools[12], although repeated subsequent builds may run dramatically faster due to build avoidance if ClearCase's make substitute can be used. Because MVFS requires server access every time a file is accessed, the performance of the file system depends on server capacity.[13]
  • Speed - Windows clients: ClearCase disk access performance for Windows clients used to be extremely low.[14] This depends on unlucky combination of a very verbose protocol combined with Samba and CIFS.[14] Replacing the windows clients standard CIFS implementation with NFS might increase the bandwidth approx. 2.5 times, leaving it still slow but more acceptable.[14]. The new CCRC client however uses the http protocol for all operations meaning this is a historic argument.
  • Sensitivity to network problems: Because MVFS is essentially an online file system, any problems with the server or network render the dynamic views unusable. It is not possible to work on dynamic views offline.[citation needed]. If the view data for dynamic views is stored on a client host (as may be done for performance reasons or to reduce the need for servers), ClearCase does not automatically handle host IP address changes.[15]

See also

Notes

  1. ^ http://www-01.ibm.com/support/docview.wss?rs=984&uid=swg21302974
  2. ^ "ClearCase - Atria Software Inc.'s software configuration management system - New Products: Development Tools - Brief Article - Product Announcement". Software Magazine. September 15, 1992. http://findarticles.com/p/articles/mi_m0SMG/is_n13_v12/ai_12606942. Retrieved 2007-12-01. 
  3. ^ "Key dates in Hardware/Software Configuration Management History". CM Crossroads LLC. 2007. http://www.cmcrossroads.com/cgi-bin/cmwiki/view/CM/HistoryOfCM. 
  4. ^ Michael Bucken (August 1995). "Complex development earns Atria an IS role; hot Unix vendor's move to Windows and NT opens IS doors - Company Profile". Software Magazine. http://findarticles.com/p/articles/mi_m0SMG/is_n8_v15/ai_17338017. 
  5. ^ Andrew DeFaria (December 21, 2004). "Re: cvs vs. clearcase?". info-cvs@gnu.org. (Web link).
  6. ^ Lawrence M. Fisher (June 7, 1996). "Pure Software To Buy Astria In Stock Deal". The New York Times. http://query.nytimes.com/gst/fullpage.html?res=940CE6DE1639F934A35755C0A960958260. Retrieved 2007-12-01. 
  7. ^ "IBM Reports 2003 First-Quarter Results". IBM. April 14, 2003. http://www-03.ibm.com/press/us/en/pressrelease/243.wss. Retrieved 2008-01-09. 
  8. ^ http://stackoverflow.com/questions/449549/how-to-leverage-clearcases-features
  9. ^ http://david.fries.net/thoughts/IBM_ClearCase_mvfs_patch.php
  10. ^ Emacs ClearCase Integration, Open Source
  11. ^ ccase.vim : Script to setup maps/menus to add in using ClearCase. - vim online
  12. ^ "Comparing Perforce and IBM Rational Clearcase" (PDF). Perforce Software (a competing vendor). 2007. http://www.perforce.com/perforce/comparisons/perforce_clearCase.pdf. 
  13. ^ "WANdisco for Subversion vs ClearCase MultiSite". WANdisco (a vendor promoting Subversion). 2007. http://www.wandisco.com/php/clearcase.php. 
  14. ^ a b c "ClearCase Build Performance Degradation: Technical Report" (PDF). Configuration Management, Inc. 2004. http://www.cmi.com/PDF/clearcase_bpd_report.pdf. 
  15. ^ "About short DHCP leases and ClearCase - Tech Note". IBM Rational. 2007. http://www-1.ibm.com/support/docview.wss?uid=swg21122137. 

References

External links


Advertisements






Got something to say? Make a comment.
Your name
Your email address
Message