バージョン管理リポジトリをどのように整理しますか？

StackOverflow https://stackoverflow.com/questions/222827

質問

まず、私はこれについて知っています：社内ソフトウェアプロジェクトの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

語彙をクリアするには：ソリューションは単一の製品を意味し、ProjectはVisual Studioプロジェクトです（単一の.dllまたは単一の.exeになります）

これが、リポジトリのレイアウト方法です。主な問題は、複数のソリューションがあることですが、ソリューション間でプロジェクトを共有することです。 これらの共有プロジェクトを独自のソリューションに移動することは本当に意味がないと考え、代わりにsvn：externalsを使用してソリューション間でプロジェクトを共有することにしました。また、リポジトリの1か所にツールとサードパーティライブラリの共通セットを保持し、svn：externalsを使用して各ソリューションでそれらを参照します。

このレイアウトについてどう思いますか？特にsvn：externalsの使用について。これは理想的な解決策ではありませんが、すべての長所と短所を考慮すると、考えられる最善の方法です。どうしますか？

役に立ちましたか？

解決

以下の推奨事項に従うと（何年もの間）、次のことができるようになります：

-プロジェクトのルートディレクトリの構造を保持している限り、各プロジェクトをソース管理の任意の場所に配置します

-最小限のリスクと最小限の準備で、あらゆるマシンのどこでも各プロジェクトを構築します

-バイナリ依存関係（ローカル＆quot; library＆quot;および＆quot; output＆quot;ディレクトリ）にアクセスできる限り、各プロジェクトを完全にスタンドアロンでビルドします

-プロジェクトは独立しているため、任意の組み合わせのプロジェクトを構築して作業します

-独立しているため、単一のプロジェクトの複数のコピー/バージョンをビルドおよび操作します

-生成されたファイルまたはライブラリでソース管理リポジトリが乱雑にならないようにします

お勧めします（牛肉はこちら）：

  1. 各プロジェクトを定義して、.DLL、.EXE、.JAR（Visual Studioのデフォルト）などの単一の主要な成果物を作成します。

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

  3. IDEに依存せずに、最初からビルドする各プロジェクトの自動ビルドスクリプトをルートディレクトリに作成します（ただし、可能であれば、IDEでのビルドを妨げないでください）。

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

  5. すべてのプロジェクトビルドスクリプトが、単一のローカル共有「ライブラリ」から外部（サードパーティ）依存関係を参照するようにします。このようなすべてのバイナリがバージョンで完全に識別されるディレクトリ：％DirLibraryRoot％\ ComponentA-1.2.3.4.dll 、％DirLibraryRoot％\ ComponentB-5.6.7.8.dll 。

  6. すべてのプロジェクトビルドスクリプトで、主要な成果物を単一のローカル共有「出力」に公開します。ディレクトリ：％DirOutputRoot％\ ProjectA-9.10.11.12.dll 、％DirOutputRoot％\ ProjectB-13.14.15.16.exe 。

  7. すべてのプロジェクトビルドスクリプトは、＆quot; library＆quot;の設定可能な完全バージョン化された絶対パス（上記を参照）を介して依存関係を参照します。および「出力」ディレクトリ、その他はありません。

  8. プロジェクトが別のプロジェクトまたはそのコンテンツを直接参照しないようにします。「出力」内の主要な成果物への参照のみを許可します。ディレクトリ（上記を参照）。

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

  10. すべてのプロジェクトビルドスクリプトは、プロジェクトのルートディレクトリに相対的な絶対パス： $ {project.base.dir} / src 、 $ {project。 base.dir} / tst （構文はビルドツールによって異なります）。

  11. ALWAYSでは、絶対に設定可能なパス（設定可能な変数で指定されたディレクトリをルートとする）を介してすべてのファイルまたはディレクトリを参照するプロジェクトビルドスクリプトが必要です： $ {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. 各マシンで、必要な環境変数を定義するシェルスクリプトを作成します。THATマシン（および、該当する場合は、そのユーザーに固有の場合もあります）。

  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：＆quot; ant.jar＆quot;を常に使用したくない「ant-a.b.c.d.jar」ではなく互換性のないバージョンのAntで無意識に実行したため、ビルドスクリプトが壊れたときに書き込みが行われた後。これは、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つのリポジトリにあるのはなぜですか？プロジェクトごとに個別のリポジトリを用意しないのはなぜですか（つまり、「ソリューション」という意味です）。

まあ、少なくとも私はone-project-per-repository-approachに慣れています。あなたのリポジトリ構造は私には複雑すぎるようです。

そして、この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 ソリューションのリリースごとに分岐することが有利な場合があります。

相対パスの問題に追加するには：

それが問題かどうかわかりません：
Solution1を＆quot; Solution1＆quot;という名前のディレクトリの下にチェックアウトするだけです。Solution2についても同じです。実際にブランチを表す「ディレクトリ」の目標は、ワークスペースにインポートした後、見えないことです。したがって、「Solution1」（実際には「Solution1 / trunk」）と「Solution2」（Solution2 / trunk）の間で相対パスが可能です。

RE：相対パスと共有ファイルの問題-

これはsvn固有のもののようですが、それは問題ではありません。別の人がすでに別のリポジトリについて言及しているので、それはおそらく、任意の他のプロジェクトを参照する異なるプロジェクトがある場合に私が考えることができる最良の解決策です。共有ファイルがない場合は、OPソリューション（および他の多くのソリューション）が正常に機能します。

私たちはまだこれを解決しており、存在しないか貧弱なバージョン管理のセットアップを引き継いだので、今解決しなければならない3つの異なる努力（異なるクライアント）があります。

同様のレイアウトを使用していますが、トランク、ブランチ、タグはすべて最上部にあります。したがって：/ trunk / main、/ trunk / utils、/ branches / release /など。

これは、翻訳ツールの多くが基本的な教科書のSVNレイアウトで最適に機能したため、他のバージョン管理システムを試してみたいときに非常に便利でした。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top