バージョン管理リポジトリをどのように整理しますか？
まず、これについて知っています： 社内ソフトウェアプロジェクト用のSubversionリポジトリをどのように整理しますか？ 次に、実際の質問：私のチームはリポジトリを再構築しており、整理方法のヒントを探していますそれ。 （この場合、SVN）。これが私たちが思いついたものです。 1つのリポジトリ、複数のプロジェクト、および複数のsvn：externals相互参照があります
\commonTools /*tools used in all projects. Referenced in each project with svn:externals*/
\NUnit.v2.4.8
\NCover.v.1.5.8
\<other similar tools>
\commonFiles /*settings strong name keys etc.*/
\ReSharper.settings
\VisualStudio.settings
\trash /*each member of the team has trash for samples, experiments etc*/
\user1
\user2
\projects
\Solution1 /*Single actual project (Visual Studio Solution)*/
\trunk
\src
\Project1 /*Each sub-project resulting in single .dll or .exe*/
\Project2
\lib
\tools
\tests
\Solution1.sln
\tags
\branches
\Solution2
\trunk
\src
\Project3 /*Each sub-project resulting in single .dll or .exe*/
\Project1 /*Project1 from Solution1 references with svn:externals*/
\lib
\tools
\tests
\Solution2.sln
\tags
\branches
ボキャブラリーをクリアするには：ソリューションは単一の製品を意味し、プロジェクトはVisual Studioプロジェクトです（単一の.dllまたは単一の.exeになります）
これが、リポジトリのレイアウトを計画する方法です。主な問題は、複数のソリューションがあることですが、ソリューション間でプロジェクトを共有することです。これらの共有プロジェクトを独自のソリューションに移動しても意味がないと考え、代わりにsvn：externalsを使用してソリューション間でプロジェクトを共有することにしました。また、リポジトリ内の1か所にツールとサードパーティライブラリの共通セットを保持し、svn：externalsを使用して各ソリューションでそれらを参照します。
このレイアウトについてどう思いますか？特にsvn：externalsの使用について。これは理想的な解決策ではありませんが、すべての長所と短所を考慮すると、考えられる最善の方法です。どうしますか？
以下の私の推奨事項に従うと（何年も持っています）、次のことができるようになります。
-プロジェクトのルートディレクトリから下の構造を保持している限り、各プロジェクトをソース管理の任意の場所に配置します
-最小のリスクと最小の準備で、あらゆるマシンのどこにでも各プロジェクトを構築
-バイナリ依存関係（ローカル「ライブラリ」および「出力」ディレクトリ）にアクセスできる限り、各プロジェクトを完全にスタンドアロンでビルドします。
-独立しているため、プロジェクトの任意の組み合わせでビルドおよび動作します
-独立しているため、単一のプロジェクトの複数のコピー/バージョンを構築して作業する
-生成されたファイルまたはライブラリでソース管理リポジトリが乱雑になるのを避ける
私はお勧めします（ここに牛肉があります）：
各プロジェクトを定義して、.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に主要な成果物を公開します。すべてのプロジェクトビルドスクリプトが、「library」ディレクトリと「output」ディレクトリ内の設定可能な完全バージョンの絶対パス（上記を参照）を介して依存関係を参照するようにします。
プロジェクトが別のプロジェクトまたはそのコンテンツを直接参照しないようにしてください。「出力」ディレクトリ内の主要な成果物への参照のみを許可します（上記を参照）。
すべてのプロジェクトビルドスクリプトが、構成可能な完全にバージョン管理された絶対パス
%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-a.b.c.d.jar」ではなく「ant.jar」で常に作業する必要はありません。これは、Ant 1.6.5と1.7.0の間で特に一般的です。一般的に、プラットフォーム（Java A.B.C.D）やビルドツール（Ant E.F.G.H）など、使用されているすべてのコンポーネントの特定のバージョンを常に知りたいと考えています。そうしないと、最終的にバグが発生し、最初の大きな問題は、さまざまなコンポーネントのどのバージョンが関係しているかを追跡することになります。その問題を前もって解決する方が簡単です。
Subversionを使用した実用的なバージョン管理 には、リポジトリを整理するために必要なものがすべて揃っていると思います。
あなたが投稿したものとほぼ完全に一致するように設定しました。一般的な形式を使用します。
\Project1
\Development (for active dev - what you've called "Trunk", containing everything about a project)
\Branches (For older, still-evolving supported branches of the code)
\Version1
\Version1.1
\Version2
\Documentation (For any accompanying documents that aren't version-specific
私はあなたの例ほど完全ではないと思いますが、それは私たちにとってうまく機能しており、物事を分離しておくことができます。各ユーザーが「スラッシュ」フォルダーを持っているという考え方も気に入っています。現在、これらのタイプのプロジェクトはソース管理に行き着かないため、常にそうすべきだと感じています。
すべてを1つのリポジトリに収めるのはなぜですか？プロジェクトごとに個別のリポジトリを用意しないのはなぜですか（「ソリューション」を意味します）。
まあ、少なくとも私は、リポジトリごとのアプローチの1つのプロジェクトに慣れています。あなたのリポジトリ構造は私には複雑すぎるようです。
そして、この1つの大きなリポジトリにいくつのプロジェクトを配置する予定ですか？ 2？ 3？ 10？ 100？
また、1つのプロジェクトの開発をキャンセルする場合はどうしますか？リポジトリツリーから削除するだけで、将来は見つけにくくなります。それとも永遠に横たわったままにしますか？または、あるプロジェクトを別のサーバーに完全に移動する場合はどうでしょうか？
そして、それらすべてのバージョン番号の混乱はどうですか？ 1つのプロジェクトのバージョン番号は2、10、11のようになり、もう1つのプロジェクトは1、3、4、5、6、7、8、9、12のようになります...
私は愚かかもしれませんが、リポジトリごとに1つのプロジェクトが好きです。
提案された構造の主な欠点は、共有プロジェクトが最初に追加されたソリューションでのみバージョン管理されることだと思います（svn：externalsが想像よりも空想的でない限り）。たとえば、Solution2の最初のリリース用にブランチを作成すると、Project1はSolution1に存在するため、ブランチされません。後でブランチからビルドする必要がある場合（QFEリリース）、ブランチの時点のProject1のバージョンではなく、最新バージョンのProject1が使用されます。
このため、共有プロジェクトを1つ以上の共有ソリューション（および構造内の最上位ディレクトリ）に配置し、any solutionのリリースごとにそれらを分岐すると有利な場合があります。
相対パスの問題に追加するには：
私はそれが問題かどうかわかりません：
Solution1という名前のディレクトリの下にあるSolution1/trunkだけをチェックアウトします。Solution2についても同じです。実際にブランチを表す「ディレクトリ」の目標は、ワークスペースにインポートされたら非表示です。したがって、「Solution1」（実際には「Solution1/trunk」）と「Solution2」（Solution2/trunk）の間で相対パスが可能です。
RE：相対パスと共有ファイルの問題-
これはsvn固有のもののようですが、それは問題ではありません。別の人がすでに別のリポジトリについて言及しているので、それはおそらく、他の任意のプロジェクトを参照する異なるプロジェクトがある場合に考えられる最良の解決策です。共有ファイルがない場合は、OPソリューション（および他の多くのソリューション）が正常に機能します。
私たちはまだこれを解決しており、存在しないか貧弱なバージョン管理の設定を引き継いだため、今すぐ解決しなければならない3つの異なる努力（異なるクライアント）があります。
レイアウトは似ていますが、トランク、ブランチ、タグが一番上にあります。したがって：/ trunk/main、/ trunk/utils、/ branches/release /など。
翻訳ツールの多くが基本的な教科書のSVNレイアウトで最適に機能したため、これは他のバージョン管理システムを試してみたいときに非常に便利でした。