ソフトウェア
開発支援

現代のソフトウェア構成管理システムは、ファイルのバリエーションを、リビジョンの識別子と同じ名前空間内で識別しています。バリエーション（ある構成要 素に対する別の実装であり、並行して存在しなければならない）と、リビジョン（各バリエーションに対して繰り返し行われる改訂）は二次元のバージョンツ リーを構成します。つまり一般的にいうと、ある構成要素は二種類の名前空間を持つことになります。その構成要素自身の名前空間と、バージョンの名前空間で す。本書では、上記に代わる方式として、バリエーションの識別を構成要素自身の名前空間に移し、バージョンの名前空間には、一次元のリビジョンの集合のみ が存在するような方式を紹介します。この方式は、それぞれの構成要素がソフトウェアのソースファイルとなるような運用システム上において考案されたことに より、インターファイル・ブランチング（Inter-File Branching^TM）と呼ばれます。「ブランチ」はバリエーションを作成すること、「ファイル」は構成要素、「インターファイル」は各バリエーションが別々のファイルであることを意味しています。

本書では、ファイルのバリエーションを扱う新しいメカニズムを紹介します。最初に、現在の方式における2つの側面、つまりバリエーションに名前をつける方 法とそれをどのように作成するかを説明し、それからその実用上の制限について引用を用いながら説明します。次に、インターファイル・ブランチング（IFB）という新しい方式にこの限界がないことを示し、そのメカニズムを詳細に説明します。最後に、実際にインターファイル・ブランチングを使用した経 験に基づく所見を紹介します。

一般的に、ファイルは二種類の名前によって識別されます。ファイル自身の名前とファイルのバージョン名です。バージョンには、二種類の情報が含まれます。それは、バリエーションの名前とそのバリエーションのリビジョン名です。ある「バリエーション」とは、並行して存在する幾つもある実装の組の1つであり、 「リビジョン」とは、あるバリエーションの中で発展してきた実装の中の1つを指します。通常、新しいバリエーションの第1リビジョンは、別のバリエーショ ンの何番目かのリビジョンです。このリビジョンが、分岐点と呼ばれます。バリエーションとリビジョンとは、分岐点で結合され、バージョンツリーを構成しま す。ここで、各バリエーションはツリーの枝であり、各リビジョンはその枝のノードです。

SCCSとRCS（その他このツールを基にした多くのシステム）において、バリエーション（実際はブランチと呼ばれます）は数字のペアで命名され、リビ ジョンはまた別の数字のペアで命名されます。「幹」には、名前はありません。例えば、1.2.2.1.1.3という表現 は、バリエーション1.2.2.1 のリビジョン 1.3 を意味します。そしてバリエーション 1.2.2.1 は、バリエーション1.2のリビジョン2.1です。さらに、バリエーション1.2は幹のリビジョン1.2です。ユーザにとって、これらの番号の意味を覚えることは決して容易ではないので、たいていの場合、重要なバージョンには印が付けられています。

ある商用SCMツール は、リビジョン番号の使用をやめ、ユーザに階層的なバージョン名を提供しています。例えばmain/release2/bugfix/3 は main という幹から派生している release2というブランチ（のどこか）から派生している bugfixブランチの第3リビジョンを表します。この命名方法は、ブランチの分岐点がわからないという点で議論の余地がありますが、SCCSの番号管理よりもはるかに記憶に残り易くなっています。

ところが、バージョンの名前空間でバリエーションを表現するという取り組み方には、欠点もあります。

二種類の階層の存在
ファイルの各バリエーションは、ファイル自身の名前とバリエーションの名前という、二種類の階層構造名を組み合わせて識別されます。私見ですが、ファイル を二種類の階層によって識別すると、ユーザは視覚的にその構成を把握することができないと考えます。理論的には、SCMシステムというのは十分機能的であ り、視覚的に把握できる必要性まではないのですが、複雑なソフトウェア製品とその複数にわたるリリースを扱うエンジニアにとって、実際には製品のファイル ツリー構造を「形」として理解する必要が頻繁に発生します。

バリエーションが必要に応じて自由に作成される場合、この事態はさらに悪化し、バージョンに対する更新が、同じバリエーションの新しいリビジョンとしてで はなく、新規に作成されたバリエーションの第1リビジョンとして管理されてしまいます。結果として、時間が経つと多くのファイルが多くの不要なバリエー ションを持つようになり、場合によっては異なったファイルに対して異なって名前付けされたバリエーションが、重要な構成の中に含まれてしまうかもしれませ ん。

意味的な違い
ファイル名に対し1つの名前空間があり、これらのファイルのバリエーションに対し別の名前空間があるということは、既存のSCMシステムユーザにジレンマ を引き起こします。なぜなら、この2つの名前空間は異なる意味を持つからです。具体的にいうと、自動差分マージ機能はバージョンの名前空間に関係します。つまり、差分のマージは、あるバリエーションから別のバリエーションへしか行えないということです。それでありながら、ユーザは一度に1つのバリエーショ ンしか参照できません。

このように、ユーザがあるバリエーションから別のバリエーションに差分をマージしようとする場合、この2つのバリエーションは同一ファイルのバリエーショ ンでなければなりません。一方、同時に両バリエーションにアクセスしたい場合、これらは異なるファイルでなければなりません。この問題は、次のような場合に生じます。すなわち、

• クライアント／サーバシステムで、クライアントとサーバのプロトコル機能の実装が似ているけれども同一ではない場合
• マルチプラットフォームシステムで、OS に依存するファイルについては、その内容が似て非なる場合
• あるプログラム言語から別の言語へ移植されたシステムで、当面CとC++での実装で同期をとる必要がある場合

などです。これらのすべての場合において、ファイルは互いにバリエーションとなりますが、実装上は別々のファイルです。

メインラインの存在
バー ジョンの名前空間を表現する場合、中心となるブランチがあり、他のすべてのブランチがそこから派生します。1つのソフトウェアプロジェクトにおける開発初 期は、この中心となるブランチで運用できますが、既存の成熟した製品、特に貧弱な SCMで開発を始めた製品の構造には適しません。このような成熟した製品の場合、本質的には異なる開発を行うためのメインラインが、同じソースファイルに対して複数存在してしまう可能性があります。

中心となるバリエーションを複数用いるような開発が行えないため、本来は同じリポジトリ内で互いにバリエーションとなるはずのファイルを、別々のリポジト リに作成しなければならなくなってしまいます。その結果、SCMシステムの自動マージやトラッキングの機能を活用できなくなります。

バリエーションの共通した表現方法は、そのままバリエーションの共通した作成方法につながります。各ファイルについて、ユーザは既存のあるバージョンを新たなバリエーションの開始点として選択します。一般的には、その選択された既存のバージョンには何らかのシンボル名が付けられていて、ユーザが個々にファ イルのバリエーションおよびリビジョンをリストしなくて済むようになっています。新しいバリエーションにも同様にシンボル名がつけられ将来的に参照しやす いようになっています。

しばしば、ユーザはバリエーション名を共有するすべてのファイルを意味してブランチを考えます。しかし、バリエーションの作成方法自身は、この集合的な意 味合いをサポートしません。つまり、単に既存のファイルのバリエーションが作成されるだけで、将来的に作成され得るファイルのバリエーションは作成されま せん。あるブランチに対する変更を別のブランチに反映させる場合、新規に作成されたファイルについては、別途それに対する新しいバリエーションを作成する必要があります。さらに重要なこととして、バリエーションの作成に使われた情報は、各ファイルのシンボル名がついた既存のバージョンであるにすぎないた め、新規のファイルに対しては、そのファイルがバリエーションを持つべきかどうか判断する外的手段がありません。

この問題への対処として、コンテナ（ディレクトリ）を構成要素として扱い、それに対して同様にバリエーションを作成するSCMシステムもあります。ただ し、このスキームはかなり複雑で混乱を招きます。個々のバージョンを識別するための名前空間を増やすだけでなく、依然として、新しいファイルが作成された ときに自動的にバリエーションを作成できません。

インターファイル・ブランチング（IFB）は、バージョンツリー・ブランチ方式よりも優れた機能を提供する、もう1つの方式です。「UNIXにおいてプロセスを forkするようにバリエーションを生成する」という点が、この方式の核となる考えになります。つまり、新しいファイルが作成され、ファイルの初期内容や過去の履 歴と関連付けられますが、その後の振舞いにおいては干渉しません。

このモデルは、SCMの助けを何も受けていないユーザが、ソフトウェアの分岐を行う必要に直面したとき、何を一般的に行うべきかということに似ています。これらのユーザは、ファイル群をコピーし、後になってどのファイルに対してマージを行うかについて頭を痛めます。この原始的な方式と IFBとでは、最初のコピーとそれに続くマージにおいて、IFB ではそれを自動化できるという点に違いがあります。IFBという方式の本質は、バリエーションに対する実践的なサポートを拡大することにあります。つまり、差分をマージしたり、マージの履歴を追跡したりできるよ うにすることによって、分離したファイル間の橋渡しをします。

IFBにおいて、バリエーションは別の名前が付けられたファイルになります。その名前はバリエーションの名前とファイルの名前を組み合わせたものにするのが普通ですが、ユーザは自由な名前を付けても構いません。例えば、ファイル /release2.1/database/src/btree.cのバリエーションを /patch2.1.5/database/src/btree.c としたり、/x/y/z のバリエーションを/a/b/c/d としたりすることができます。

IFBという方式は、バリエーションを作り出すためにファイルのコピーを行うという、慣れ親しんだ操作に基づいています。その上で、バリエーションに類似の名前を与えることによって、元のバリエーションと新しいバリエーションとの関係をユーザにわかり易くします。例えば、ユーザはしばしばファイル foo.cを単純に foo.c.bak にコピーします。ところが、mainline/src/* を bob/src/*にコピーする方がよかったかもしれません。そうすれば、Bobのファイルはメインラインのバリエーションであり、お互いに関係していることが暗黙の内にわかります。

もし、このコピーがユーザの個人的な作業空間ではなく SCMリポジトリの中で行なわれるのであれば、結果的にリポジトリの名前空間は、ユーザにとって参照し易いものとなります。IFBは、ファイルのバリエーションを識別するために、ユーザに単一のハンドル（名前）を与えます。これによって構成の「姿」は、ユーザにとってわかり易いのも のになります。上の例のように Bobは、自分の作業のための構成が、「リポジトリの中の、bob/src/*配下にあるものすべて」という形で簡単に識別できます。

分離したファイルとしてバリエーションを取り扱うことにより、IFB をサポートしているSCMシステムでは、いかなるファイルのペアにおいてもマージと追跡を実行できます。元々お互いに関係がなかったファイルに対してさえ、バリエーションという意 味を「後付け」で与えることが可能です。SCMの管理下にすらなかったかもしれない任意の2つのファイルを取り出して、お互いのバリエーションとして扱い始めることができるということです。

IFBでは、バリエーションは異なった名前を持ちます。実際のところ、それらの名前を似せる必要はありません。これによって、ある構成全体のバリエーション（す なわち、ある構成における全ファイルのバリエーション）を作成することができます。その構成では、新規作成されたバリエーションに対して自由に命名するこ とで、プロセスにおける名前空間を完全に再構成することができるのです。これは、さまざまな場面において有効です。とりわけ、ソフトウェアが、コードを共 有しながら別のプロジェクトに分岐するときには特に有効です。新しいプロジェクトでは、必要に応じて「組み替えられた」ソフトウェアのコピーをぜひとも欲しいかもしれません。

IFBは、ファイルの名前空間を介して、バリエーション間を関連付けます。したがって、各要素ファイルの名前の関係を表現することによって、構成全体を関連付け ることができます。もし、この関係表現が、ソフトウェアの自然な組織化を表しているならば、それは非常に簡潔なものになるでしょう。例えば、Bobのコードがメインラインのコードのバリエーションであるということは、「bob/src/* は mainline/src/*のバリエーションである」ということです。この表現は、存在するファイルを関連付けているだけでなく、その名前空間の中で作成される可能性のある、あらゆ るファイルに対しても関連付けを行います。

バージョンの名前空間はもはやバリエーションの名前を保持しないので、それぞれのファイルに対する直線的リビジョン番号（1から順に付けられた番号）の集 合に減らすことができます。このことは、「名前空間中の特定の一部分に存在するファイル群の先端（最大の番号、最新）リビジョンの集合は、しばしば重要な構成である」ことを意味します。例えば、Bob の作業の最新版は、bob/src/*と名前付けされたファイル群の先頭リビジョンの集合になります。

インターファイル・ブランチングにおけるマージの自動化は、次のような前提に基づきます。すなわち、マージの元となる1つのファイル（「マージ元」）が与えられたとき、その個々の差分の何れか、またはそのすべてを、マージの宛先となる1つのファイル（「マージ先」）の内容に対してマージすることに意味があ るという前提です。これには、新規に空（から）のファイルへ記述した、最初の差分も含みます。マージ元のファイルとマージ先のファイルの対応を決めるの は、それらの名前です。まず、ユーザはあるマージ元を選び、マージしたい差分を選び、マージ先を選びます。次に、以下の論理が適用されます。

• 差分が連続していない場合には、連続している部分ごとに以降の論理を適用します。
• マージ先がファイルとして存在しない場合には、マージ元の内容をそのまま使って、最新リビジョンが作られます。これは、一般に「ブランチ」として参照されるもので、同一内容を持つ新しいバリエーションの始まりです。
• ター ゲットが存在する場合には、選択されたリビジョンの中から最新のものを用いて、マージ元の内容とマージ先の内容をマージしなければなりません。マージの結 果は、マージ先ファイルにおける次のリビジョンとなります。基準となる適切なリビジョンが見つけられる場合には、一般的な差分／マージのアルゴリズムに よって、自動化できます。自動マージの基準は、選択されたマージ元のリビジョンの中で最も古いものより1つ前のリビジョンになります。もし、選択された マージ元のリビジョンの中で最も古いものがマージ元の最初のリビジョンだった場合、基準となるリビジョンは存在しないことになります。その場合には、ユー ザはマージ先の内容をマージ元の内容で置き換えるか、マージ先の内容をそのままにするか、マージ元とマージ先の内容から、手動で差分の取捨選択を行うこと になります。
• いずれの場合にも、マージ先の新しいリビジョンとして、選択されたマージ元の差分を取り込んだということが、恒久的に記録されます。この時点で、マージ元とマージ先は、お互いのバリエーションとして考えることができます。

あるファイルから他のファイルへマージされた差分の記録は、指定された一対のファイルに関して、統合へ至るまでの履歴を形作ります。これは、2つの重要な機能を提供します。まず1つは、統合の履歴によって「いくつかの差分が、あるファイルから別のファイルへマージされている」ことが判れば、マージ先はマー ジ元のバリエーションであると言える点です。もう1つは、統合の履歴により、どの差分をこれからマージしなければならないかを計算できることです。この情 報を使って、あらゆるマージに対してマージ元の差分を、ユーザに選ばせることができることになります。

また、統合の履歴は、監査の証跡に使用することもできますし、包括的な報告書の作成に使用することもできます。第一世代、第二世代、第三世代といった各世 代のマージを通じて、他のファイルからどのような差分が統合されたのか、どのファイルのどのバージョンに関しても計算することが可能になります。

バリエーションのファイルが、それらの名前によってお互いに関係を持つには、その関係を表すものが必要になります。この仕事をブランチビューが行います。ブランチビューとは、2つのファイルパス名を1対1に対応付けるもので、名前が付けられます。この一対のファイルパスは、マージが予定されているブランチ の、マージ元とマージ先になります。ブランチビューを用いることにより、すべての既知のファイル名は、そのビューを介してマージ元の候補として対応付けら れます。これから得られたマージ元とマージ先のペアは、ブランチまたはマージされるべきファイルを定義します。

このメカニズムには、2つの重要な側面があります。1つは、それぞれのブランチビューでは、ビューの中のマージ元とマージ先において1対1の対応付けのみ が許可されますが、それぞれのマージ元とマージ先に関して、複数のブランチビューがあり得るということです。つまり、同じマージ元が多数の異なるマージ先にブランチできますし、マージ先も1つ以上のマージ元のバリエーションとなり得ます。もう1つは、その対応付けが行われるのは、ユーザが要求したときのみ のことであり、マージの可能性をもったマージ元が生成または更新されたときではないということです。つまり、ブランチ先の生成やマージを要求したりしたと きに限り、ブランチビューが適用されるということです。

ブランチビューは、あるユーザがマージ先にマージ元の内容を反映させようとするための、単なる記述に過ぎません。実際のマージは、ブランチビューの適用に より行われます。そのユーザが要求することにより、存在するすべてのファイルの名前がそのビューを介して投影されて、マージ元／マージ先に組み合わせのリ ストが作られます。各組み合わせに対して統合の履歴が考慮されて、統合についての案がユーザに提示されます。こうした変更提案（新しいバリエーションにお ける第1リビジョンを作成したり、既存のバリエーションにおける新リビジョンを作成したり、マージ元が既に削除されている場合にこのバリエーションにおい ても削除する等）によって、マージ元の変更差分がマージ先に反映されるわけです。これらの変更を実際にどの程度行うか（すべてを取り込むか、部分的に変更するか、すべての変更を止めるか）は、もちろんユーザの判断によります。ユーザが、2つの構成をまったく同じであるように維持し続けようとすることはまれ です。

前に、統合の履歴（すなわち、ソースファイル中のどの差分がターゲットファイルにマージ済みであるのかを個々に記録したもの）を使い、どの差分をマージす るべきかを正確に算出できると述べました。この算出結果は、3ウェイの比較／マージ（three-way diff/merge）の基準を形成するバージョンとして役に立ちます。この基準となるリビジョンは、マージ元リビジョンの中で、マージされるべき最初の リビジョンよりも1つ前のリビジョンになります。

マージ元とマージ先における変更の衝突を解決させる通常の方法は、共通の祖先を探し、比較／マージの処理における基準として、その祖先を使用することで す。この処理では、基準となるリビジョンから各バリエーションのリビジョンに対して施された変更を、テキスト上の差分として計算し、その差分をマージしま す。この方式は、かなり多くのツールで用いられており、RCSが持つ単純なrcsmergeコマンドから、各バージョンの変更行を色分けするような、高機 能のGUIにまで至ります。

ほとんどのツールは、共通の祖先として最初の分岐点を用います。ところが、残念なことに2つのバリエーションの内容が共通の祖先からかけ離れていけばいく ほど、2つのバリエーションの間では、ますます多くの変更行が衝突を起こし、それが重なっていきます。これでは、マージを行うたびに、以前のマージで解決されてきた衝突を、あらためて調べなければなりません。共通の祖先として最初の分岐点を用いない方式として、ある商用SCMツールの機能がそうであるよう に、マージ元からマージされた最も新しい差分の内容を記録するという方式があります。しかし、この方式は、差分が常に順にマージされていることを前提にし ています。しかしながら、例えば、「バグ修正を行った差分だけをすぐにマージし、それ以外のマージは後回しにしたい」というようなことが、ときどき発生し ます。

マージ済みの個々の差分を追跡することで、マージのための最適な基準、つまり最初にマージされるべきリビジョンに対して、その1つ前のリビジョンを見つけ ることができます。これにより、基準のリビジョンとマージ元の最新リビジョンとの間の差異を最小限にし、結果としてマージの複雑さを最小限にすることがで きます。

あるバリエーションから別のバリエーションへマージされた差分を、統合の履歴が個々に追跡しているので、「純粋」な統合を理解することによって、ある特別な利点が得られます。純粋な統合とは、単一のマージ元からの差分だけを取り込んで、マージ先に新しいリビジョンを作るような統合のことです。純粋な統合の結果として作られた差分は、マージ元に対して、逆向きのマージを行う必要がないという点で重要です。

統合の履歴がないと、「マージ先の新しい差分が、別のただ1つのバリエーションからの差分をマージして作られた」とは言い切れません。そして、後に自動マージを行おうとすると、それが新しい差分として見つかり、マージ元に対して逆向きのマージを行うことになります。初めのマージによって差分がそのまま マージされた場合は、逆向きのマージにおいて何らかの操作が発生するはずはなく、ユーザにとって考慮する事柄はほとんどありません。しかし、マージ先に対して行った初めのマージにおいて、衝突の解決や別の編集を必要としたときには、差分を逆向きにマージするにあたって、ユーザは再びその解決策を調べなけれ ばなりません。

純粋な統合を記録した履歴を用いることにより、自動マージにおいて、マージ元に対する逆向きのマージは必要なくなります。実際の操作としては、統合が純粋な状態に保たれるような何らかの手がかりを、ユーザは示さなければなりません。つまり、衝突の解決をするときに、そこで行った変更がマージ元にも戻すべき変更であること示します。その操作の最後で、ユーザは統合が純粋に保たれているということを実際に確認しなければなりません。このようにすることにより、 統合履歴はその事実を記録することができます。そしてこの記録により、マージ元に対して差分を逆向きにマージしようとする自動的な動きが抑止されるように なります。

ファイルの階層的な名前空間の中でバリエーションの識別も行うならば、バリエーション名を示すための場所が必要です。これは主に個々の使い方の問題に帰す るのですが、単純なケースではファイル名の最初にバリエーションの名前を入れることによって、ファイルツリー全体の内容がわかり易くなります。例えば、開 発中のメインラインが/main/src/…の下にあり、/release2.1/src/...にそのブランチを作成した場合、ファイルツリーの意味を理解するのは非常に容 易です。

あるファイルが、ユーザの管理下（ファイルシステム下）にあるとき、そのファイルがSCMリポジトリ内における名前と一致する必要がないということは重要です。もし、その名前にバリエーションを表す部分が組み入れられているならば、ファイルを ユーザの作業空間にコピーするとき、そのバリエーションの情報はファイルから取り除かれるのが望ましいでしょう。このために、クライアントビューがありま す。各クライアントの作業空間はビュー（ブランチビューと非常によく似ています）を持っており、リポジトリ内のファイル名をユーザのローカルファイルシス テムに投影します。こうすることで、単一のエンティティ（クライアントビュー）によって、ユーザが参照するファイルだけでなく、ユーザが見たいバリエー ションをも特定します。さらに、このビューによってそれぞれのバリエーションに対してクライアントから見たときの名前を異なるようにすると、クライアント は2つの異なるバリエーションを扱うことさえできるようになります。

ファイルをブランチすることによってリポジトリ内にファイルをコピーするということになると、実用上はディスク容量が問題になります。これに対する簡単な解決策は、仮想的なコピーを行って、新規にブランチしたファイルについては元々のファイルの内容を使うということです。これを実現するには、リポジトリの名前空間と実際のオブジェクト格納場所との間に、ある程度の遠回りな手順が必要になります。ブランチに新バージョンが付加されると、分岐したファイルはオ ブジェクト格納場所に別の実体を獲得します。

仮想的なコピーを用いてバリエーションを実装することにより、新規作成されたバリエーションが単に元々のファイルを指し示すだけのものならば、バリエーションのためのディスク領域は節約されます。

この仮想的なコピーは、明示的に別のバリエーションと同期を取っている場合に使うこともできます。ユーザがあるブランチをメインラインに戻して同一の内容としたい場合、ブランチとメインラインはその時点で同じ内容を参照することができます。

本書では、よく知られているSCMシステム（フリーツール、商用ツール）で見られるバージョンツリーモデルと対照させてIFBを述べてきました。バリエーションをサポートするためには更に2つのアプローチがあります。

ベースライン・モデル[2]はIFBから見ると、かなり単純化されたものといえます。厳密にいえば、ベースラインとは単に将来行う変更の基礎を提供するた めの構成です。しかしながら、一般的には、その構成での内容をコピーして作られたファイルが実際のベースラインになります。この点で、IFBのコピーに似ています。新しいベースライン自身がオリジナルの構成と明確に区別された名前を持っているからです。

IFBと比較して、ベースライン・モデルは次の3つの点で制限されます。1つは、名称の関係が確定していることです。通常、ベースラインには名前があり、ベースライン中のファイルはベースライン間で一定の名前を持っています。2つめは、ベースラインは前もって決められているところの、通常は「プロジェク ト」とか「プロダクト」とかいうファイルセットだということです。1つや2つのファイルのバリエーションを作るのは不可能なのです。3つめは、統合履歴が、ベースラインについてはかなり制限されます。例えば、あるバリエーションから他のバリエーションにマージされた1つ1つのデルタを追跡することはでき ません。

チェンジセット・モデル[7]とICEのバージョンセット・モデル[10]は、実際にはIFBとは好対照のものになります。この両方のモデルとも、各ファ イルに関し、バリエーションと変更バージョンは名前付きのバージョンツリーを形成しません。その代わり、各ファイルには、バージョン（ほとんど無意味です が）を生成するために任意に当てはめられるデルタの集合を持っています。チェンジセット・モデルでは、適用されるデルタの組み合わせは「チェンジ・セッ ト」と呼ばれ、チェンジ・セット自身は名称を持った構成の一部として記録されます。ICEのバージョンセット・モデルでは、デルタは「機能」と呼ばれる属 性を持ち、正しい属性の組み合わせを持つデルタを見つけることにより、適用対象のデルタを選択します。

両モデルともバージョンツリーモデルとよく比較されますが、IFBとは著しく異なっています。IFBはリポジトリの名前空間内でバリエーションを区別しま す。そのためにユーザは独立したファイルとしてバリエーションを取り扱うことができます。他方、両モデルはファイルの全バリエーションを1つのエンティ ティとし、その機会のたびにユーザに欲しいバージョンを選択する（あるいは、作成する）ことを求めてきます。

まとめると、IFBでは、重要な構成を、その要素のファイル名のみで識別することができるのに対して、バージョンツリーでは、重要な構成が「主幹」上には ないことが多いので、バリエーションに明確な名前をつけなければなりません。チェンジセット・モデルとICEのバージョンセット・モデルでは、重要な構成には、チェンジ・セットや機能の一覧による明確な仕様が必ず要求されます。

IFBモデルの初期バージョンは、Ingres社のPiccoloと呼ばれる社内SCMシステムの一部に実装されました。それには、現在のモデルにおける ブランチビューと統合履歴での詳細機能がありません。そのため、まずバリエーションを作るのは厄介で、ユーザはブランチされた特定のファイルを列挙しなけ ればなりませんでした。また、しばしばこのシステムでは、繰り返しマージされたデルタを、後にマージバックしなければなりませんでした。

それにもかかわらず、IFBは、並行開発とリリースを実行するための確固とした基盤であることを証明しました。3つの大陸に散らばった数百人の開発者とエ ンジニアは、Piccoloのブランチを使って、おそらくは総計12000ファイルになる多くの製品をサポートしました。いつでも、多くのリリースが同時に進行中でした。

ほとんどの場合に、リポジトリに格納されたファイルの名前を構成する最初の部分からブランチが作られました。系のメインコードは、開発コード で"main"と呼ばれました。ここから、各開発者やグループ用に多くのブランチが作られ、開発者やプロジェクトにちなんで名前がつけられました。同様に、主要なリリースのたびに、そのリリースにちなんだ名称を持ったブランチが作られました。こうした主要なリリースは、それぞれがサブのメインラインとな り、それらからパッチブランチが生まれました。

IFBの思いがけない利点の1つは、ブランチには任意の2つのファイルにおける名前の関係が現われるので、メインコードとは違ったツリー構造をもつブラン チを、開発者が自由に作れることでした。これにより、開発者は自分たちのニーズに合うようにカスタマイズした環境で製品をビルドしたり保守したりできまし た。例えば、あるグループがメインコードの名前空間において「かなりかけ離れた」ディレクトリを担当している場合があります。便宜を図るために、自分たち のグループのブランチ内でこれらのディレクトリを一緒にすることができます。

IFBに関するここで述べたような現行モデルは、Perforceという商用システムに実装されています。PerforceはIFBの考え方に従い、Piccoloで見つかった欠陥を修正した、考え抜かれたシステムです。Perforceは新しいものですが、以前の経験から、そのモデルが柔軟で、実用 性があり、完全なものであることがわかっています。未だ大規模で成熟したソフトウェア製品に対する適用事例はありませんが、このような製品開発において、 統合履歴の記録が有用な情報を与えるものであることを期待しています。

伝統的なバリエーションの処理方法の多くが、基本的に不自然なモデルに従っています。たとえ、現行SCMシステムの熟練ユーザが、バリエーションと変更バージョンを組み合わせた名前空間の使い方を理解しているとしても、このアプローチが根本的に持っている弱点により、結局は総合的能力の点で大きなギャッ プを生み出します。他方、IFBは、ソフトウェアファイルを別の名前でコピーするという自然なモデルから出発しており、実用性に富む多くのテクニックを蓄 積するに至っています。与えられた機会において、IFBは伝統的なバリエーションの処理機能を凌駕することができるでしょう

[1] Atria Corporation, ClearCase Concepts Manual. Natick Massachusetts, 1994

[2] Bersoff, Henderson, Siegel, Software Configuration Management. Prentice-Hall, 1980.

[3] Susan Dart, The Past, Present, and Future of Configuration Management. Technical Report CMU/SEI-92-TR-8, Software Engineering Institute, Carnegie Mellon University, 1992.

[4] Stephen MacKay, The State of the Art in Concurrent, Distributed Configuration Management. Proceedings of the 5th International Workshop on Software Configuration Management, Seattle, WA, 1995.

[5] Rochkind, The Source Code Control System. IEEE Transactions on Software Engineering, Volume SE-1, December 1975.

[6] Roger Rohrbach and Christopher Seiwald, Galileo: A Software Maintenance Environment. Proceedings of the International Workshop on Software Version and Configuration Control, Grassau, 1988.

[7] Software Maintenance and Development Systems (SMDS). Aide-de-Camp Users Manual, Concord Mass, 1993.

[8] Walter Tichy, RCS -- a system for version control. Software -- Practice and Experience, July 1985.

[9] Walter Tichy, Tools for Software Configuration Management. Proceedings of the International Workshop on Software Version and Configuration Control, Grassau, 1988.

[10] Andreas Zeller, Smooth Operations with Square Operators -- The Version Set Model in ICE. Informatik-Bericht No. 95-08, Technical University of Braunschweig, Germany, 1995.