| Clearcase |
Website Links For Ibm |
Information AboutClearcase |
| CATEGORIES ABOUT IBM RATIONAL CLEARCASE | |
| ibm software | |
| rational clearcase | |
| software engineering | |
| proprietary version control systems | |
|
Rational ClearCase is a Software tool for Revision Control ( Configuration Management , SCM etc) 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, but the price is quite steep for smaller companies. Rational supports two types of SCM configurations, UCM , and base ClearCase. UCM provides an out-of-the-box SCM configuration while base ClearCase supplies all the basic tools to make it very configurable and flexible. Both can be configured to support a wide variety of SCM needs. ClearCase can run on a number of platforms including Linux , Solaris and Windows . It can handle large binary files, large numbers of files, and large repository sizes. It handles branching, labeling, and versioning of directories. HISTORY 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. It is a popular product used by software production companies. 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:
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. VIEWS 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 . 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 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 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-private" 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-private 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/her 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 config spec. This is a Collection Of Rules (stored internally in a text file, but compiled in core at run-time) 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. A sample configuration specification could look like this:
# 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.
# For all files named 'somefile', regardless of location, always show the latest version on the main branch. element .../somefile /main/LATEST ### Actually, the comment for the line above is incorrect. That rule will # only select somefile@@/main/LATEST if there is not a checked out version (rule #1) # or if there is not a version on the /module2_dev_branch (rule #2). CC will not look # any further once it finds a match, so the original comment for this rule is true # only for following rules, not the first 2 rules # 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 A configuration specification can also reference other configuration specifications using the 'include' statement. UNIQUE FEATURES
WEAKNESSES
SEE ALSO REFERENCES EXTERNAL LINKS
|
|
|