4

「通常の」svnディレクトリ構造とは異なり、私は次の構造を使用しています。

トランク/
  project1 /
  project2 /
  project3 /
  ..。
ブランチ/
  project1-ブランチ/
    project1 /
    project2 /
    ..。
  project2-ブランチ/
    project1 /
    project2 /
    ..。
タグ/
  project1 /
    V1
    V2
    ..。

ご覧のとおり、プロジェクトごとに個別のトリプル（トランク/ブランチ/タグ）はありません。

開発のために、必要なすべてのプロジェクトを含むトランクのチェックアウト（場合によってはスパースチェックアウト）を実行します（プロジェクト間には依存関係があり、一部のプロジェクトは単なるライブラリです）。

これに見られる利点は次のとおりです。

  • すべてのプロジェクトに共通のルートディレクトリ（トランク）があるため、更新とチェックインは簡単です。1つは単純であるsvn updateか、svn commitそれをすべて行います。

  • タグまたはブランチの作成は簡単です。これを行うために必要なのはトランクだけだからsvn copyです。（ブランチとタグには実際には必要以上のプロジェクトが含まれていますが、asvn copyは安価であり、必要に応じてブランチまたはタグでスパースチェックアウトを実行できます。）

  • リソースはすべて同じリポジトリにあるため、あるプロジェクトから別のプロジェクトへのリソースの移動は簡単です。

  • トランクのフルチェックアウトに取り組んでいるときは、プロジェクトを見逃さないようにすることができるため、グローバルリファクタリング（たとえば、一般的に使用されるクラスのパッケージの変更）は簡単です。

  • あるプロジェクトから別のプロジェクトへのリファクタリングの移動があった場合でも、ブランチ全体を一度にマージできるため、マージは簡単です。

私はMavenに移行し、すべてのプロジェクトをトランクからMavenプロジェクトに分割するつもりです。Mavenの依存関係管理と利用可能なプラグインの恩恵を受けたいです（現在、巨大なカスタムantファイルを使用しています）。

今私の質問は次のとおりです。

  • すべてのプロジェクトに独自のトリプル（トランク/ブランチ/タグ）を与えるためにsvnディレクトリ構造を変更する必要がありますか？答えは「はい」だと思います。

  • 構造を変更した場合、上記の利点のどれが失われますか（つまり、Mavenでそれを行うとより複雑になることを意味します）？

  • Mavenでそれを行うための同等の方法は何ですか？

4

2 に答える 2

13

「通常の」svnディレクトリ構造など、そのようなものはありません。Subversion を使用したバージョン管理ブックの「リポジトリ構成の計画」というセクションで説明されているように、さまざまなアプローチがあります ( 、、名前でさえ単なる規則であり、タグとブランチの間に違いはありません。ただし、それらの認識を除きます)。 ./trunk/tags/branches

  • すべてのプロジェクトに独自のトリプル (トランク/ブランチ/タグ) を与えるために、svn ディレクトリ構造を変更する必要がありますか? 答えは「はい」だと思います。

いいえ、する必要はありません。たとえば、Apache ServiceMix ソース ツリーを参照してください。これはマルチ モジュールの maven プロジェクトですが、モジュールは 1 つの下にありますtrunk。一方、単一の製品ではなく、製品とプロジェクトのエコシステムであるXWiki には、そのソース リポジトリページで詳しく説明されているように、多くのトランク/ブランチ/タグがあります。ここでリポジトリを参照して、レイアウトのアイデアを得ることができます。

しかし、どちらのアプローチを選択するかは好みの問題ではなく、実際にはリリース サイクルに依存します (詳細はmvn release後述)。プロジェクトのコンポーネントが同じバージョン (ServiceMix 風) を共有している場合は、トランクを 1 つだけ使用します。それらが独立したリリース サイクル (XWiki 風) を持っている場合、このスレッドで説明されているような複数の「トランク/タグ/ブランチ」構造を使用します。

myrepo
  + .links (2)
    + trunks
      + pom.xml
  + parent-pom (1)
    + trunk
      + pom.xml
  + project-A
    + trunk
      + pom.xml
  + project-B
    + trunk
      + pom.xml

1) プロジェクトの親 POM には、独自のリリース サイクルがあります。すべてのコンポーネントの POM は、それを親として使用します (単純にgroupIdand artifactId、 noで参照されrelativePathます)。リリースの場合、最初に親 POM をリリースする必要があります。

2) これは、プロジェクトの特定のブランチ (通常はトランク) を簡単にチェックアウトできるようにするための構造です。Subversion ユーザーは myrepo/.links/trunk をチェックアウトして、すべてのソースの最新リビジョンを取得します。秘訣は、そのディレクトリに svn:externals、このプロジェクトの他のすべてのモジュール (parent-pom、project-A、project-B) のトランクへの外部リンク (つまり、プロパティを含む) が含まれていることです。このディレクトリの pom.xml は決してリリースされません。これには、マルチ モジュール ビルドを有効にする 3 つのモジュールのモジュール セクションが含まれているだけです。このコンストラクトを使用すると、ブランチを簡単にセットアップできます。

myrepo
  + .links
    + branch-2.x
      + pom.xml

私はこのセットアップを何度も使用しましたが、非常にうまく機能します。

  • 構造を変更すると、上記の利点のどれが失われますか?

それぞれのポイントに一つずつお答えしましょう。

  • svn externalsのおかげで、更新とチェックインは簡単です。1 つの単純なsvn updateまたはsvn commitすべてを行います。

  • タグまたはブランチの作成は簡単です。Maven リリース プラグインがこれを処理してくれるからです (そして、タグとブランチはよりクリーンになります)。

  • あるプロジェクトから別のプロジェクトへのリソースの移動は、それほど複雑に見えません。

  • グローバルなリファクタリング (一般的に使用されるクラスのパッケージの変更など) は、トランクの完全なチェックアウトで引き続き作業できるため、簡単です。

  • マージはそれほど簡単ではない場合があります。しかし、クラスをあるプロジェクトから別のプロジェクトにそんなに頻繁に移動しますか?

  • Mavenでそれを行う同等の方法は何ですか?

必要に応じて、maven リリース プラグインと、svn 外部で推奨されるレイアウトの 1 つを使用します。

于 2009-10-17T22:02:02.620 に答える
1

依存関係の管理にのみMavenを使用したい場合で、プロジェクト構造がすでに十分である/うまく機能していると思われる場合は、役立つヒントを次に示します。Mavenを忘れてください。

Mavenは単なる依存関係管理ツールではなく、それ自体を「ソフトウェアプロジェクト管理および理解ツール」と呼んでいます。これは明らかに依存関係だけでなく、他の多くの基盤もカバーします。依存関係の管理だけが必要なので、少なくとも依存関係の管理のみを目的として存在するAntIvyなどのツールを確認する必要があります。

Ivyの本当の利点は、既存のプロジェクト構造、ビルドスクリプト、およびその上にすでに構築したほぼすべてのものを維持しながら、Mavenよりもはるかに優れた詳細な依存関係管理に取り組むことができることです。Ivyは、プロジェクトの構造や構成パターンを強化しません。依存関係管理ツールから取得したいものを定義し、それをプロジェクトに追加することができます。プロジェクトを象牙の塔の一部の人々が構造的に表現するものにする必要はありません。 。

さらに決定を助けるために、ここに両方の​​当事者による互いの比較があります：

于 2009-10-17T10:35:10.370 に答える