[解決済み] バージョンコントロールのリポジトリはどのように整理されていますか？

質問

まず、このことを知っています。 インハウスソフトウェアプロジェクトのための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 の使用について。これは理想的なソリューションではありませんが、すべての長所と短所を考慮すると、私たちが考えた最善の方法です。あなたならどうしますか？

どのように解決するのですか?

以下の私の推奨事項に従えば（私は何年もそうしてきました）、あなたはできるようになります。

-- プロジェクトのルート ディレクトリから下の構造を維持する限り、各プロジェクトをソース管理のどこにでも置くことができる。

-- 最小限のリスクと最小限の準備で、あらゆるマシンのあらゆる場所に各プロジェクトを構築する。

-- バイナリの依存関係 (ローカルの "library" および "output" ディレクトリ) にアクセスできる限り、各プロジェクトを完全にスタンドアロンでビルドすることができます。

-- 各プロジェクトは独立しているため、任意の組み合わせでビルドし、作業することができます。

-- 単一のプロジェクトの複数のコピー/バージョンで構築し、作業することができます。

-- 生成されたファイルやライブラリでソースコントロールリポジトリが散らからないようにする。

をお勧めします（ここがビーフです）。

1. .DLL、.EXE、または .JAR (Visual Studio でのデフォルト) などの単一の主要な成果物を生成するように各プロジェクトを定義する。

2. 各プロジェクトを 1 つのルートを持つディレクトリ ツリーとして構造化します。

3. IDE に依存せず、ゼロから構築する各プロジェクトの自動構築スクリプトをルート ディレクトリに作成します (ただし、可能であれば IDE で構築することを妨げない)。

4. Windows の .NET プロジェクトのための nAnt、または OS やターゲット プラットフォームなどに基づいた同様のものを検討してください。

5. すべてのプロジェクトのビルド スクリプトで、単一のローカル共有 "library" ディレクトリから外部 (サード パーティ) 依存関係を参照し、バージョンによって完全に識別されたバイナリを使用するようにします。 %DirLibraryRoot%\ComponentA-1.2.3.4.dll , %DirLibraryRoot%\ComponentB-5.6.7.8.dll .

6. すべてのプロジェクト ビルド スクリプトで、単一のローカル共有 "output" ディレクトリに主要な成果物を発行するようにします。 %DirOutputRoot%\ProjectA-9.10.11.12.dll , %DirOutputRoot%\ProjectB-13.14.15.16.exe .

7. すべてのプロジェクトのビルド スクリプトが、"library" と "output" ディレクトリで、設定可能で完全にバージョン管理された絶対パス (上記参照) を介してその依存関係を参照し、それ以外の場所にはないようにすることです。

8. プロジェクトが他のプロジェクトやその内容を直接参照することは決してありません。"output" ディレクトリ内の主要な成果物への参照のみを許可します (上記を参照)。

9. すべてのプロジェクトのビルド スクリプトが、設定可能で完全にバージョン管理された絶対パスによって、必要なビルド ツールを参照するようにします。 %DirToolRoot%\ToolA\1.2.3.4 , %DirToolRoot%\ToolB\5.6.7.8 .

10. すべてのプロジェクトのビルドスクリプトが、プロジェクトのルートディレクトリからの相対的な絶対パスによってソースコンテンツを参照するようにします。 ${project.base.dir}/src , ${project.base.dir}/tst (のようになります（構文はビルドツールによって異なります）。

11. プロジェクトのビルドスクリプトには、必ず絶対パス（設定可能な変数で指定されたディレクトリをルートとする）を使用して、すべてのファイルまたはディレクトリを参照するように要求します。 ${project.base.dir}/some/dirs または ${env.Variable}/other/dir .

12. プロジェクトのビルドスクリプトが、以下のような相対パスで何かを参照することは決して許されません。 .\some\dirs\here または ..\some\more\dirs のように、必ず絶対パスで記述してください。

13. プロジェクトのビルドスクリプトで、ルートディレクトリが設定されていない絶対パスを使用して、次のようなあらゆるものを参照することを決して許可しないでください。 C:\some\dirs\here または \\server\share\more\stuff\there .

14. プロジェクトビルドスクリプトによって参照される設定可能な各ルートディレクトリについて、それらの参照に使用される環境変数を定義します。

15. 各マシンを構成するために作成しなければならない環境変数の数を最小限にするよう試みます。

16. 各マシンで、必要な環境変数を定義するシェルスクリプトを作成します。これは、そのマシンに固有のものです (関連する場合は、そのユーザーに固有のものである可能性もあります)。

17. マシン固有の設定シェルスクリプトをソース管理に入れないでください。代わりに、各プロジェクトで、テンプレートとしてプロジェクトのルートディレクトリにそのスクリプトのコピーをコミットしてください。

18. 各プロジェクトのビルド スクリプトで各環境変数をチェックし、それらが定義されていない場合は意味のあるメッセージで中断することを要求します。

19. 各プロジェクト ビルド スクリプトは、依存するビルド ツール実行ファイル、外部ライブラリ ファイル、および依存するプロジェクト成果物ファイルのそれぞれをチェックし、それらのファイルが存在しない場合、意味のあるメッセージで中断するように要求されます。

20. プロジェクトの成果物、生成されたソース、生成されたドキュメントなど、生成されたファイルをすべてソース管理にコミットする誘惑に負けないようにします。

21. IDE を使用している場合、できる限りのプロジェクト制御ファイルを生成し、それらをソース制御にコミットしないでください (Visual Studio プロジェクト ファイルを含む)。

22. すべての外部ライブラリとツールの公式コピーを持つサーバーを確立し、開発者のワークステーションとビルドマシンにコピー/インストールする。 ソース管理リポジトリと一緒にバックアップしてください。

23. 開発ツールを一切使用しない継続的インテグレーションサーバー（ビルドマシン）を構築する。

24. Ivy (Antと併用)などの、外部ライブラリや成果物を管理するツールを検討してください。

25. Mavenは使わないでください--最初は喜んでいたのに、最終的には泣きを見ることになるでしょう。

このどれもが Subversion 固有のものではなく、そのほとんどは、あらゆる OS、ハードウェア、プラットフォーム、言語などを対象としたプロジェクトに一般的なものであることに注意してください。 OS やツール固有の構文を少し使用しましたが、これは説明のためだけであり、選択した OS やツールに翻訳していただけると信じています。

Visual Studio ソリューションに関する追加の注意事項: それらをソース管理内に置かないでください! このアプローチでは、ソリューションがまったく必要ないか、または (Visual Studio プロジェクト ファイルのように) 生成することができます。 しかし、私は、ソリューション ファイルを個々の開発者が適当に作成/使用できるようにするのが最善だと考えています (ただし、ソース管理にはチェックインしない)。 私は Rob.sln ファイルを自分のワークステーションに置いて、そこから現在のプロジェクトを参照しています。 私のプロジェクトはすべてスタンドアロンなので、私は自由にプロジェクトを追加/削除することができます (つまり、プロジェクト ベースの依存関係の参照はないということです)。

Subversion の外部参照 (または他のツールでの類似) を使用しないでください。

継続的インテグレーションを実装するとき、または単にリリースプロセスを自動化したいときでさえ、そのためのスクリプトを作成します。 プロジェクト名 (リポジトリにリストされているもの) とタグ名をパラメーターとして受け取り、設定可能なルート ディレクトリ内に一時ディレクトリを作成し、与えられたプロジェクト名とタグ名のソースを (Subversion の場合は適切な URL を構築して) その一時ディレクトリにチェックアウトし、テストを実行して成果物をパッケージするクリーン ビルドを実行する、単一のシェル スクリプトを作成します。 このシェルスクリプトはどのプロジェクトでも動作し、ビルドツールプロジェクトの一部としてソースコントロールにチェックインする必要があります。 継続的インテグレーションサーバーは、このスクリプトをプロジェクト構築の基盤として使用することができますし、それを提供することもできます (ただし、あなた自身のスクリプトが必要かもしれません)。

@VonC: Ant-a.b.c.d.jar" ではなく "ant.jar" で常に作業したいとは思わないはずですが、知らずに互換性のないバージョンの Ant で実行し、ビルドスクリプトが壊れたときに火傷します。これは特に Ant 1.6.5 と 1.7.0 の間でよくあることです。一般論として、プラットフォーム (Java A.B.C.D) やビルドツール (Ant E.F.G.H) を含め、使用しているすべてのコンポーネントのバージョンを常に把握しておく必要があります。 そうでなければ、いずれバグに遭遇したとき、最初の大きな問題は、様々なコンポーネントのどのバージョンが関係しているかを追跡することでしょう。 その問題を前もって解決しておくことは、単に良いことです。