以下の推奨事項（私は何年も持っています）に従うと、次のことができるようになります。
-プロジェクトのルートディレクトリから下の構造を維持する限り、各プロジェクトをソース管理の任意の場所に配置します
-最小限のリスクと最小限の準備で、各プロジェクトを任意のマシンの任意の場所に構築します
-バイナリ依存関係（ローカルの「ライブラリ」および「出力」ディレクトリ）にアクセスできる限り、各プロジェクトを完全にスタンドアロンでビルドします。
-プロジェクトは独立しているため、プロジェクトの任意の組み合わせを構築して使用する
-独立しているため、単一のプロジェクトの複数のコピー/バージョンをビルドして操作する
-生成されたファイルまたはライブラリでソース管理リポジトリが乱雑にならないようにします
私はお勧めします（ここに牛肉があります）：
各プロジェクトを定義して、.DLL、.EXE、.JAR（Visual Studioではデフォルト）などの単一の主要成果物を作成します。
各プロジェクトを単一のルートを持つディレクトリツリーとして構造化します。
IDEに依存せずに、プロジェクトを最初からビルドするルートディレクトリ内の各プロジェクトの自動ビルドスクリプトを作成します（ただし、可能であればIDEでのビルドを妨げないでください）。
Windows上のnAnt for .NETプロジェクト、またはOS、ターゲットプラットフォームなどに基づいた類似のものを検討してください。
完全にはバージョンによって識別されるすべてのバイナリで、単一のローカルの共有「ライブラリ」ディレクトリからすべてのプロジェクトのビルドスクリプト参照にその外部（サードパーティ）の依存関係を作ります： %DirLibraryRoot%\ComponentA-1.2.3.4.dll、%DirLibraryRoot%\ComponentB-5.6.7.8.dll。
すべてのプロジェクトのビルド・スクリプトは、単一のローカル共有「出力」ディレクトリに主要成果物を公開してください：%DirOutputRoot%\ProjectA-9.10.11.12.dll、%DirOutputRoot%\ProjectB-13.14.15.16.exe。
すべてのプロジェクトビルドスクリプトが、「ライブラリ」ディレクトリと「出力」ディレクトリ内の構成可能で完全にバージョン管理された絶対パス（上記を参照）を介して、その依存関係を参照し、他にどこにもないようにします。
プロジェクトに別のプロジェクトまたはそのコンテンツを直接参照させないでください。「出力」ディレクトリ（上記を参照）の主要な成果物への参照のみを許可してください。
すべてのプロジェクトのビルド・スクリプトが設定可能とフルバージョン管理、絶対パスでその必要なビルドツールを参照してください： %DirToolRoot%\ToolA\1.2.3.4、%DirToolRoot%\ToolB\5.6.7.8。
プロジェクトのルートディレクトリへの絶対パス相対することにより、すべてのプロジェクトのビルドスクリプトリファレンスソースコンテンツを作成します ${project.base.dir}/src、${project.base.dir}/tst（構文は、ビルド・ツールによって異なります）。
常に、絶対的で構成可能なパス（構成可能な変数で指定されたディレクトリをルート）を介してすべてのファイルまたはディレクトリを参照するためのプロジェクトビルドスクリプトが必要です：${project.base.dir}/some/dirsまたは${env.Variable}/other/dir。
プロジェクトビルドスクリプトが.\some\dirs\hereやなどの相対パスを..\some\more\dirs使用して参照することは絶対にしないでください。絶対パスを常に使用してください。
プロジェクトビルドスクリプトが、C:\some\dirs\hereまたはなどの構成可能なルートディレクトリを持たない絶対パスを使用してすべてを参照することを許可しないで\\server\share\more\stuff\thereください。
プロジェクトビルドスクリプトによって参照される構成可能なルートディレクトリごとに、それらの参照に使用される環境変数を定義します。
各マシンを構成するために作成する必要がある環境変数の数を最小限に抑えるようにしてください。
各マシンで、THATマシンに固有の（場合によってはそのユーザーに固有の）必要な環境変数を定義するシェルスクリプトを作成します。
マシン固有の構成シェルスクリプトをソース管理に置かないでください。代わりに、プロジェクトごとに、プロジェクトのルートディレクトリにあるスクリプトのコピーをテンプレートとしてコミットします。
各プロジェクトビルドスクリプトに各環境変数を確認するよう要求し、定義されていない場合は意味のあるメッセージを表示して中止します。
各プロジェクトビルドスクリプトを要求して、その依存ビルドツール実行可能ファイル、外部ライブラリファイル、および依存プロジェクト成果物ファイルのそれぞれをチェックし、これらのファイルが存在しない場合は意味のあるメッセージを表示して中止します。
生成されたファイルをソース管理にコミットする誘惑に抵抗してください-プロジェクトの成果物、生成されたソース、生成されたドキュメントなどはありません。
IDEを使用する場合は、できる限りのプロジェクト管理ファイルを生成し、それらをソース管理にコミットしないでください（これにはVisual Studioプロジェクトファイルが含まれます）。
すべての外部ライブラリとツールの公式コピーを備えたサーバーを確立し、開発者のワークステーションとビルドマシンにコピー/インストールします。ソース管理リポジトリとともにバックアップします。
開発ツールがまったくない継続的インテグレーションサーバー（ビルドマシン）を確立します。
Ivy（Antで使用）などの外部ライブラリと成果物を管理するためのツールを検討してください。
Mavenを使用しないでください。最初はあなたを幸せにし、最終的には泣かせます。
これはSubversionに固有のものではなく、OS、ハードウェア、プラットフォーム、言語などを対象とするプロジェクトに一般的なものであることに注意してください。OSとツール固有の構文を少し使用しましたが、説明のみを目的としています-私はあなたがあなたの選択したOSやツールに翻訳することを信じます。
Visual Studioソリューションに関する追加の注意：ソース管理に配置しないでください！このアプローチでは、それらをまったく必要としないか、または（Visual Studioプロジェクトファイルのように）生成できます。ただし、ソリューションファイルを個々の開発者に任せて、適切に作成/使用できるようにするのが最善です（ただし、ソース管理にチェックインされていません）。Rob.sln現在のプロジェクトを参照するファイルをワークステーションに保持しています。プロジェクトはすべてスタンドアロンであるため、プロジェクトを自由に追加/削除できます（つまり、プロジェクトベースの依存関係の参照はありません）。
Subversionエクスターナル（または他のツールで類似）は使用しないでください。これらはアンチパターンであるため、不要です。
継続的インテグレーションを実装する場合、またはリリースプロセスを自動化するだけの場合でも、そのためのスクリプトを作成します。プロジェクト名（リポジトリにリストされている）とタグ名のパラメーターを受け取り、構成可能なルートディレクトリ内に一時ディレクトリを作成し、指定されたプロジェクト名とタグ名のソースをチェックアウトする（その一時ディレクトリへのSubversionの場合は適切なURL）、テストを実行して成果物をパッケージ化するクリーンビルドを実行します。このシェルスクリプトはどのプロジェクトでも機能し、「ビルドツール」プロジェクトの一部としてソース管理にチェックインする必要があります。継続的インテグレーションサーバーは、プロジェクトを構築するための基盤としてこのスクリプトを使用できます。また、スクリプトを提供することもできます（ただし、独自のスクリプトが必要な場合もあります）。
@VonC：互換性のないバージョンのAntで無意識に実行したため、ビルドスクリプトが壊れたときに焼き付けられた後は、「ant-abcdjar」ではなく「ant.jar」を常に使用したくない。これは、Ant 1.6.5と1.7.0の間で特に一般的です。一般化すると、プラットフォーム（Java ABCD）やビルドツール（Ant EFGH）など、使用されているすべてのコンポーネントの特定のバージョンを常に知りたいと思っています。そうしないと、最終的にバグが発生し、最初の大きな問題は、さまざまなコンポーネントのどのバージョンが関係しているかを追跡することになります。単にその問題を前もって解決するほうがよいです。