• バージョン・コントロール・システム (VCS) によって、チーム開発のための規範が提供されます。
• VCS はソース・コードに加えられた変更を追跡し、制御します。
• すべてのファイルがいつ、誰によって変更が加えられたかを追跡することができます。
• また、欠陥を取り除くために 1 つ前のバージョンに戻すことも比較的簡単にできます。これはファイル・レベルだけでなく、システム全体も可能です。
• ソースコードのロック、マージ、復元、ソース比較、その他様々な管理が行われます。

上の図では、バージョン3 の簡単なファイルにテキスト"Milk Eggs Juice"というテキストが含まれています。開発者はこれをチェックアウトして、作業用コピーを"Milk Eggs Soup"と修正します。この修正がチェックインされると、これは VCS ではリビジョン 4 (r4) となります。もしくは、この変更がリビジョン 3 に戻されると、作業用コピーは"Milk Eggs Juice"となります。これは単純な概念ですが、非常にパワフルな仕組みです。まず、簡単に元に戻すことができるということ、そして、変更は VCS により管理されるので、加えた修正はそのままの形で記録され、将来いつでもその修正に戻ることができるようになります。ですから、開発者は修正を自由に試すことができます。

上図のシナリオでは、メイン・トランクがリビジョン 4 で枝分かれして同時並行の開発 (リビジョン 5) が作成されています。これはメイン・トランクで引き続きバグ修正が行われ、適用されている間に製品の新機能を追加するためです。開発者はこの枝分かれに直接入って、新機能 "Rice" を追加します。これがリビジョン 6 になります。この変更は次に新しいリリースが必要になる時まで保留にされ、メイン・トランクに戻ってマージされます。

この間に現場から報告されたバグにより、"Bread" が追加され、これがバグ修正として発行されます。こうすることで、新機能の修正は顧客には渡ることはありません。これはリリース用のプログラムと分離されていたからです。

そして、次のバージョンがリリースされる時期が来ると、新機能がメイン・トランクに戻されてマージされます。ファイルには"Rice"が追加されて、結果的に"Milk Eggs Soup Bread Rice"となります。この手順はほぼ自動化されています。システムは追加された変更をほぼ正確に加えることができます。ただし、同じ行が修正された場合は競合が報告され、変更を VCS に追加してリビジョン 8 を作成する前に、この競合を解決しなければいけません。この競合がこのシナリオでも発生しています。4 行目がメイン・トランクでも枝分かれした開発でも修正されたからです。ここでは、メイン・トランクの修正に新機能の変更が加えられた後、両方の修正が残されなければならないと開発者が判断しました。

次のトピックも参照してください。
『LANSA/AD ユーザーガイド』の「タスクの処理」