例えば、Joe の実行可能プログラム toolkit.exe の 作業 バージョンが、guilib.lib ライブラリーにリンクされています。Joe は guilib.lib を変更していないため、そのライブラリーのワーキング・バージョンは必要としません。しかし、実行可能プログラムはそのライブラリーにリンクされているため、Joe は作業を完了するためにそのライブラリーを必要とします。guilib.lib への最新の変更を取得する準備ができると、Joe は、guilib プロジェクトが開発プロジェクトのメンバーであることを確認します。次に Joe は、プロジェクトを更新して、新しくビルドされたプロダクト・ファイルを導入します。
この例に基づいて、Joe が 10 個から 15 個の異なるプロジェクト (どれも変更を必要としていなかった) からプロダクトを使用していたものとします。Joe は、プロジェクトごとに開発プロジェクトを必要とします。そのため、必要なオブジェクトを導入するための更新に余分な時間がかかることになります。外部プロジェクトを使用すると、この状況が改善されます。
外部プロジェクトには、プロダクトと、そのプロダクトを使用する必要のあるヘッダーファイルのみが含まれます。(そのプロジェクトは、他のプロジェクトがファイルを使用できるようにするために外部に置かれますが、それらのファイルが作成されたプロジェクトの外部でもあります。)
外部プロジェクトは、他のプロジェクトと対応するものであるため、類似した名前を付けると役に立ちます。例えば、guilib プロジェクトに対応する外部プロジェクトには、guilib_ext などの名前を付けます。 (元のプロジェクトではなく外部プロジェクトを参照するように makefile を変更することが容易になるように、同じ構造を維持することも有効です。) ヘッダーファイルを必要とせず、ライブラリーのみを追加できる Java™ などの一部のプログラムでは、サブプロジェクトを追加する必要はありません。
これで、ビルド・マネージャーは、外部プロジェクトおよびプロダクトが統合テストに合格した後で、それらにチェックインするベースラインを作成することができます。コードでプロダクトを参照している開発者は、外部プロジェクトを共有できます。開発者は、個人的に変更する必要のないプロジェクトについては、ワーキング・バージョンを必要としません。
開発者は、更新時にビルド・マネージャーによって最も新しくチェックインされたプロダクトを共有します。サイトでベースラインを使用しない場合は、プロダクトと外部タスクが統合テストに合格してから、それらをチェックインしてください。外部プロジェクトを使用する場合は、外部ベースライン・プロジェクト用に、全員が表示できるワークエリアを作成します。