以下の私の推奨事項に従うと（私は何年も前から持っています）、次のことができるようになります。
--プロジェクトのルートディレクトリから下にある構造を保持している限り、各プロジェクトをソース管理の任意の場所に配置します
-最小限のリスクと最小限の準備で、任意のマシンのどこにでも各プロジェクトを構築します
--バイナリ依存関係（ローカルの「ライブラリ」および「出力」ディレクトリ）にアクセスできる限り、各プロジェクトを完全にスタンドアロンでビルドします
-プロジェクトは独立しているため、プロジェクトの任意の組み合わせを構築して操作します
--独立しているため、単一のプロジェクトの複数のコピー/バージョンをビルドして操作します
-生成されたファイルまたはライブラリでソース管理リポジトリが乱雑にならないようにします
私はお勧めします（これが牛肉です）：
各プロジェクトを定義して、.DLL、.EXE、.JAR（Visual Studioのデフォルト）などの単一の主要な成果物を作成します。
各プロジェクトを単一のルートを持つディレクトリツリーとして構造化します。
ルートディレクトリにプロジェクトごとに自動ビルドスクリプトを作成します。このスクリプトは、IDEに依存せずに、最初からビルドします（ただし、可能であれば、IDEでのビルドを妨げないでください）。
Windows上の.NETプロジェクト、またはOSやターゲットプラットフォームなどに基づく同様のプロジェクトのnAntを検討してください。
すべてのプロジェクトビルドスクリプトに、単一のローカル共有「ライブラリ」ディレクトリからの外部（サードパーティ）依存関係を参照させ、そのようなすべてのバイナリをバージョンで完全に識別します： %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ください。
プロジェクトビルドスクリプトによって参照される構成可能なルートディレクトリごとに、それらの参照に使用される環境変数を定義します。
各マシンを構成するために作成する必要のある環境変数の数を最小限に抑えてください。
各マシンで、必要な環境変数を定義するシェルスクリプトを作成します。これは、そのマシンに固有です（関連する場合は、そのユーザーに固有である可能性があります）。
マシン固有の構成シェルスクリプトをソース管理に入れないでください。代わりに、プロジェクトごとに、プロジェクトのルートディレクトリにあるスクリプトのコピーをテンプレートとしてコミットします。
各プロジェクトビルドスクリプトに各環境変数をチェックするように要求し、それらが定義されていない場合は意味のあるメッセージで中止します。
各プロジェクトビルドスクリプトを要求して、依存するビルドツールの実行可能ファイル、外部ライブラリファイル、および依存するプロジェクトの成果物ファイルをそれぞれチェックし、それらのファイルが存在しない場合は意味のあるメッセージで中止します。
生成されたファイルをソース管理にコミットする誘惑に抵抗します。プロジェクトの成果物、生成されたソース、生成されたドキュメントなどはありません。
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」で常に作業する必要はありません。これは、Ant1.6.5と1.7.0の間で特に一般的です。一般化すると、プラットフォーム（Java ABCD）やビルドツール（Ant EFGH）など、使用されているすべてのコンポーネントの特定のバージョンを常に知りたいと思うでしょう。そうしないと、最終的にバグが発生し、最初の大きな問題は、さまざまなコンポーネントのどのバージョンが関係しているかを追跡することです。その問題を前もって解決する方が簡単です。