Subversionでは、マルチプロジェクトリポジトリのコンポーネントのバージョンを管理する方法は？

次のようなリポジトリの組織を想像してください：

/Project1/branches
          /tags/Rel-1.0
          /trunk
/Module1/branches
           /tags/Rel-1.0
           /tags/Rel-1.1
           /tags/Rel-2.0
           /trunk
/Module2/branches
           /tags/Rel-1.0
           /tags/Rel-1.1
           /tags/Rel-1.2  
           /tags/Rel-1.3
           /tags/Rel-2.0
           /tags/Rel-2.1         
           /trunk

プロジェクト1はModule1とModule2を使用しています。 project1のリリース1.0は、Module1とModule2のリリース1.0を使用して行われます。

プロジェクト1の新しいリリース（例1.1では、大きな進化ではない）は、Module1のリリース2.0とModule2の2.1を使用して行われます。

Subversionを使ってどうすればいいですか？

2
追加された
ビュー: 8
源
ro ru fr es pt de hi bn ar be

2 答え

各エンティティ（プロject、Module1、Module2、...、ModuleN）ごとに別々のリポジトリに分割し、リポジトリの再編成を提案し、コードを直接埋め込むのではなく、すべてのモジュールに対してプロject Repoのsvn：externalsを使用します。

開発段階では外部のHEADを参照してください。プロジェクトのタグ付けの前にプロjectのすべてのリリースで（特別なタグとしてマークされていますか？）、プロジェクトを編集して、含まれているモジュールの一部の修正版に外部を凍結する必要があります。

プロ

  • 独立したサブパーツに（SVNの点で）デポピメントの履歴を区切ります。
  • タグ付きリリースごとにリンクされたモジュールのバージョンは簡単に識別できます
  • reposはもっと単純なコードツリーを持つでしょう
  • /忘れたもの/

コントラ

  • history of プロject will not be transparent due to the presence of a bifurcation point and work with ancient revisions (before bifurcation) will give (can give) some headache
1
追加された
源

私はSVNの外で（JavaverseのApache MavenやIvyを考えて）依存関係管理を解決しようとします。

それがSVNでなければならない場合、特別なタグ名はどうですか？したがって、ビルドシステムがProject1のRel-1.0ビルドコードの /Module1/branches/deps/Project1/Rel-1.0 のような、依存するバージョンの特別なフォルダでビルドシステムが検索するという概念を導入することができますニーズ。

/Project1/branches
          /tags/Rel-1.0
          /trunk
/Module1/branches
           /tags/Rel-1.0
           ...
           /tags/Rel-2.0
           /deps/Project1/Rel-1.0
           /deps/Project1/Rel-1.1
           /trunk
/Module2/branches
           /tags/Rel-1.0
           ...
           /tags/Rel-2.1         
           /deps/Project1/Rel-1.0
           /deps/Project1/Rel-1.1
           /trunk

タグフォルダを参照することによって、扶養家族のためのフォルダを作成することができます。

# dependencies to Module1
svn cp http://myServer/svn/Module1/branches/tags/Rel-1.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.0
svn cp http://myServer/svn/Module1/branches/tags/Rel-2.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1
# dependencies to Module2
svn cp http://myServer/svn/Module2/branches/tags/Rel-1.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.0
svn cp http://myServer/svn/Module2/branches/tags/Rel-2.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1

後でバージョンを切り替えると、次のようになります

# delete old reference
svn rm http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1
# make other one for new version
svn cp http://myServer/svn/Module1/branches/tags/Rel-2.1 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1

このアプローチの欠点は、SVNの作業ディレクトリのために必要なスペースが増えることです。

1
追加された
源
私はこのアプローチの問題は、SVNはこのようなもののために構築されていないことだと思います。 Repoや作業コピーからメタデータを読み込み、適切なものを適切に構築する独自のビルドプロセス（make、cmakeなど）を作成する必要があります。少なくとも読書はXML（コマンドラインで svn ls -xml http：// server/repo/path/to/list のように）を使ってうまくやることができます。もう1つのアプローチは、現在の依存関係を記述したプロジェクトまたはモジュールのパスにファイルを置くことです。それはビルドツールで読み取って実行することができます。
追加された 著者 chabicht, 源
makeのようなビルドツールを使用している場合、あなたはすでにバージョン管理下にあるファイルを持っています。依存関係の記述を makefile ...：o）
追加された 著者 chabicht, 源
私のプロジェクトはC ++で書かれています。一部のコンポーネントはサードパーティのライブラリでもあります。私の第一の目的は、リポジトリに最適なプロジェクトと図書館の組織を見つけることです。私の2番目の目標は、SVNの下で、アプリケーションがどのように構成されているか（モジュールが組み込まれているか、どのバージョンであるか）を簡単に知り、管理できるかどうかを確認することです。
追加された 著者 Manu13, 源