7

現在、次の標準のSubversionリポジトリレイアウトを持つプロジェクトがあります。

./trunk
./branches
./tags

ただし、OSGiとモジュラープロジェクトの道を進んでいると、次のようになります。

./trunk/bundle/main
./trunk/bundle/modulea
./trunk/bundle/moduleb ./tags/bundle/main-1.0.0
./tags/bundle/main-1.0.1
./tags/bundle/modulea -1.0.0

'build'は、すべてのモジュールを順番にビルドするという点でまだかなりモノリシックですが、ビルド/リポジトリを次のようなものにリファクタリングする必要があるかどうか疑問に思い始めています。

./bundle/main/trunk
./bundle/main/tags/main-1.0.0
./bundle/main/tags/main-1.0.1
./bundle/modulea/trunk
./bundle/modulea/tags/modulea- 1.0.0

このパターンでは、各モジュールがそれ自体を構築し、そのバイナリをリポジトリ（maven、ivy、またはSubversionリポジトリ自体の別のパス）に格納することを想像します。

モジュール化された後のプロジェクトレイアウトに関するガイドラインまたは「ベストプラクティス」はありますか？

4

4 に答える 4

7

Subversion book には、これに関する 2 つのセクションがあります。

件名のブログエントリ: 「Subversion リポジトリのレイアウト」

簡単に言えば、マイレージはさまざまですが (すべての状況は個人によって異なります)、/bundle/<project>/(trunk|tags|branches)スキームはかなり一般的であり、うまく機能する可能性があります。

于 2008-08-18T10:45:46.640 に答える
6

これは個人的な好み次第ですが、多くのモジュールで構成される大規模なプロジェクトに適した構造は次のとおりです。

枝
  プロジェクト名
    module1
      支店名
    module2   
      おそらく-別のブランチ名
    両方のモジュールを含む上位レベルのブランチ名
      module1
      module2
タグ
  ...（ブランチと同じ）
トランク
  プロジェクト名
    module1
    module2

また、多くのプロジェクトを含む大規模なリポジトリでこの構造を使用することもよくあります。これは、すべてのプロジェクトを同じリポジトリに保持すると、プロジェクトの相互参照と、プロジェクト間でのコードの共有（履歴付き）が容易になるためです。

私の経験では（多くのプロジェクトを含む大規模なリポジトリで）、多くのサブプロジェクトとモジュールに個別のタグやブランチがないため、最初からルートトランク、タグ、ブランチフォルダーを含む構造を使用するのが好きです。それらのフォルダ構造を作成します。また、開発者がリポジトリのトランク全体をチェックアウトし、すべてのタグとブランチを取得する必要がないようにします（ほとんどの場合必要ありません）。

これはプロジェクトや会社の方針の問題だと思います。プロジェクトごとに1つのリポジトリがある場合、または特定の開発者が一度にリポジトリ内の1つのプロジェクトでのみ作業する可能性が高い場合、ルート化されたトランクはあまり意味がない可能性があります。

于 2008-08-18T10:27:55.473 に答える
3

ちょうど私の2セント...

SVNドキュメントのコメントを強調したいだけです（別の回答、同じスレッドですでに引用されています）http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html#svn.reposadmin.projects .chooselayout

抜粋は、次の構造を参照しています。

「このようなレイアウトについて特に間違っている点はありませんが、ユーザーにとって直感的に見える場合とそうでない場合があります。特に、多くのユーザーがいる大規模な複数プロジェクトの状況では、それらのユーザーは 1 つまたは 2 つのプロジェクトしか知らない傾向があります。リポジトリ内. しかし、プロジェクトをブランチの兄弟として使用することは、プロジェクトの個性を強調せず、単一のエンティティとしてプロジェクトのセット全体に焦点を当てる傾向があります. しかし、これは社会的な問題です.過去、現在、タグ付け、分岐など、そのプロジェクトとそのプロジェクトだけの履歴全体を保持する単一のリポジトリ パスがあると、単一のプロジェクトの履歴全体について質問する (または変更するか、別の場所に移行する) のが簡単になります。」

私自身の場合、私はこれに非常に強く同意する傾向があり、次のレイアウトを好みます: / utils/ calc/ Trunk/ tags/ Branchs/ Calendar/ Trunk/ Tags/ Branchs/ … Office/ Spreadsheet/ Trunk/ Tags/ Branchs/

その理由は、特定のサブセットのみにタグを付けたい場合に、完全なプロジェクト セットにタグを付けるのは実際的ではないからです。

例を使用してみましょう: project-1 が moduleA v1.1 と moduleB v2.3 に依存している場合、新しい moduleA v2.x をタグに表示したくありません。実際、数日、数週間、または数か月後にこのタグ付きリリースに戻ると、project-1 のタグ付きバージョンのバンドル記述子を開いて、実際に必要な moduleA のバージョンを読み取る必要がありました。

さらに、このリリースのソースの特定のバックアップを CD に作成する必要がある場合、何百メガバイトもの無関係なものをダウンロードすることなく、このタグをエクスポートしたいだけです。

それはちょうど私の2セントでした。

于 2009-03-04T12:04:35.207 に答える
0

StackOverflowバージョン管理構造の質問で同様の質問に回答しました。私たちは大量のOSGi開発を行っており、バンドルがたくさんあるので、実際にはここでさらにうまく適合します。Anders Sandvigのコメントをエコーする必要があります。限られたモジュールのセットのみを分岐するため、トランク/タグ/分岐をルートレベルに維持します。また、モジュールを個別に構築することにも干渉しません。

以前に行った回答はコピーしませんが、この質問に完全に関連しています。

于 2008-08-20T08:13:59.340 に答える