Rational ClearCase は、ソースコードなどのソフトウェア開発資産のためのバージョン管理システム（構成管理、SCMも含む）である。IBM のラショナル部門が開発している。ClearCase は中規模以上の大きな商用ソフトウェアプロジェクトでよく使われ、数百人から数千人の開発者を管理できる。ClearCase 本体にも SCM 機能があるが、それとは別に UCM という SCM 機能もある。Linux、Solaris、Windowsといった様々なプラットフォーム上で動作する。巨大なバイナリファイルや多数のファイル、巨大なリポジトリを扱える。分岐、ラベル付け、ディレクトリのバージョン付けなどが可能。ClearCase は1992年、Atria Software が UNIX 向けに開発し、後に Windows 版もリリースされた。Atria の開発者の一部はそれ以前にアポロコンピュータの "DSEE"（Domain Software Engineering Environment）の開発に携わっていた。1989年にアポロコンピュータがヒューレット・パッカードに買収されると、彼らはアポロを離れ、Atria に移ったのである。Atria は後に Pure Software と合併して PureAtria となった。それがさらにラショナルに吸収され、さらに IBM に買収された。IBM はその後も ClearCase の開発と販売を続けている。ソフトウェア開発企業にとっては ClearCase は有名な製品である。DSEE には ClearCase に見られる様々な概念が既に導入されていた。Domain/OS のファイルシステムでは、ファイルアクセス時に特殊なハンドラプログラムを呼び出すことができ、DSEE はそれを使って、特定のファイルがオープンされたときに自動的にバージョン管理されたコピーと入れ替えていた。バージョン機能はユーザー環境に常駐しており、バージョン管理されたファイルへのアクセスは全てリダイレクトされ、印刷やエディタでの参照も例外ではない。DSEE の中心となるのは、全てのソフトウェアモジュールとそれらの依存関係を記述したファイルである。このファイルは手動で作成する必要があり、大規模システムではその作業が重大な障害となった。しかし、いったん作成できれば、DSEE はビルドを行うのに最適な方法を計算でき、現在のビルドとバージョン指定が同じであるような以前に処理された全モジュールを再利用できた。DSEE はまた、"version spec" または "thread" の概念を導入した。これはあるユーザー環境やビルドにおいて、含まれても良いバージョンのリストである。重要な点は、thread においてビルドのシグネチャやソフトウェアリリースのシグネチャが利用できるようにした点である。従って、1つの thread に含まれる要素は次のようになる。thread はファイルごとに一番上から一番下まで処理された。ある開発者の thread は、一番上に確保されたものがあり、それにラベル付きバージョンが続いているかもしれない。既存リリースを素早くバグ修正する場合、thread は「確保」されたものとリリースのシグネチャ付きのものとなることもある。Domain/OS のファイルシステムの機能（不可視なリダイレクト）は通常備わっていないため、ClearCase は後述するように MVFS（MultiVersion File System）という仮想ファイルシステムを使う。"thread" の概念は "dynamic view" に対応している。ある view における派生オブジェクト（ビルドによって生成されるオブジェクト）のサポートは、DSEE の考え方に類似している。ClearCase でバージョン管理されているオブジェクトは、その履歴情報と共にリポジトリに格納されている。このリポジトリを VOB（Versioned Object Base）と呼ぶ。ClearCase で特徴的な点は、そのバージョン化ファイルシステム（MVFS）であり、"dynamic view" を通して VOB を仮想ファイルシステムとしてマウントでき、一貫性のあるバージョン群を選んで派生オブジェクトを生成できる。dynamic view はこれを Software Configuration にマップできる。これはリポジトリ/サンドボックス型とは異なり、製造物を初期段階から管理できる（チェックイン前から管理でき、ソースファイルだけでなく派生オブジェクトも管理できる）。それとは別に、ClearCase は "snapshot view" と呼ばれるものもサポートしており、これは1つまたは複数のVOBにまたがったディレクトリツリーの単なるコピーである。snapshot view は、VOB のデータへのアクセスに仮想ファイルシステムを使用しない。その代わり、snapshot view は VOB データのコピーをローカル（ユーザーのコンピュータ）に保持する。snapshot view はネットワークが切断されていても利用でき、後で接続が確立したときにVOBと同期させることができる。この操作モードは、CVS (Concurrent Versions System) が一般に使われているモードと似ている。クライアントコンピュータ上のソフトウェアという観点では、view は別のファイルシステムに見える。view 内で新たなファイルを通常のOSの手段を使って作成した場合（コピーやエディタのセーブなど）、ClearCase はそのファイルを "view-private" ファイルとして生成する。そのファイルは他の view からは見えない。このため、開発者各人が同じディレクトリ構成でビルドしていたとしても、個々の開発者の修正は他人の環境には影響を与えない（ただし、dynamic view であれば、ファイルアクセスに分散ファイルシステムが絡んでくるので、オーバーヘッドがかかる）。view-private ファイル（あるいはディレクトリ）は任意の時点でバージョン管理される要素に変換でき、それによって他の開発者からも見えるようになる。各開発者は一般に1つ以上の view を使って作業する。開発者間で view を共有できた方が便利な場合もあるが、ブランチの共有が使われるのが一般的である。ブランチの階層がよく使われ、開発プロジェクト全体で1つの開発ブランチを共有し、その中の小さいチームがサブブランチを共有し、個々の開発者が個人的なブランチを持つ。ある修正がより大きなグループに対しても十分に安定していると判断したとき、それを親ブランチとマージすることができる。ClearCase では、各 view は対応する "configuration specification" で制御される（"config spec" などと呼ぶ）。これはドメイン固有言語の一種でテキストファイルに格納されていて、実行時に自動的にコンパイルされる。config spec には、その view で見えるべき要素（ファイルやディレクトリ）とそれら要素のバージョンが指定されている。ある要素のどのバージョンが見えるべきかを決定する際、ClearCase は configuration specification を先頭から一行ずつ一致が見つかるまで見ていく。configuration specification の例を以下に示す。configuration specification は、'include' 文を使って他の configuration specification を参照できる。

出典:wikipedia