複数のSubversionプロジェクト間の関係の処理

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

質問

私の会社では、1つのSVNリポジトリを使用してC ++コードを保持しています。コードベースは、共通部分（インフラストラクチャとアプリケーション）、およびクライアントプロジェクト（プラグインとして開発）で構成されています。

リポジトリのレイアウトは次のようになります。

  • インフラストラクチャ
  • App1
  • App2
  • App3
  • project-for-client-1
    • App1-plugin
    • App2-plugin
    • 構成
  • project-for-client-2
    • App1-plugin
    • App2-plugin
    • 構成

クライアントプロジェクトの一般的なリリースには、プロジェクトデータと、プロジェクトデータで使用されるすべてのプロジェクト（インフラストラクチャなど）が含まれます。

各ディレクトリの実際のレイアウトは-

です
  • インフラストラクチャ
    • ブランチ
    • タグ
    • トランク
  • project-for-client-2
    • ブランチ
    • タグ
    • トランク

その他のプロジェクトについても同様です。

上記のレイアウトにはいくつかの問題があります：

  1. 関連するすべてのプロジェクト（インフラストラクチャ、App1、App2、client-for-client-1など）をチェックアウトする必要があるため、クライアントプロジェクトの新しい開発環境を開始するのは困難です。
  2. 上記と同じ理由で、クライアントプロジェクトでリリースにタグを付けるのは困難です。
  3. クライアントプロジェクトで一般的なコード（インフラストラクチャなど）を変更する必要がある場合、ブランチを使用することがあります。プロジェクトで使用されているブランチを追跡するのは困難です。

上記のいずれかを解決する方法はSVNにありますか？クライアントプロジェクトでsvn：externalsを使用することを考えましたが、この投稿は正しい選択ではないかもしれないことを理解しています。

役に立ちましたか？

解決

これはsvn：externalsで処理できます。これは、svnリポジトリのスポットへのURLです これにより、異なるリポジトリ（または同じリポジトリ）の一部を取り込むことができます。これを使用する1つの方法は、project-for-client2の下で、必要なインフラストラクチャのブランチ、必要なapp1のブランチなどにsvn：externalsリンクを追加することです。したがって、project-for-client2をチェックアウトすると、すべての正しい部分。

svn：externalsリンクは他のすべてと一緒にバージョン管理されるため、project-for-client1がタグ付けされ、分岐され、更新されると、正しい外部ブランチが常に取り込まれます。

他のヒント

提案は、ディレクトリレイアウトを変更することです

  • インフラストラクチャ
    • ブランチ
    • タグ
    • トランク
  • project-for-client-1
    • ブランチ
    • タグ
    • トランク
  • project-for-client-2
    • ブランチ
    • タグ
    • トランク

to

  • ブランチ
    • 機能-1
      • インフラストラクチャ
      • project-for-client-1
      • project-for-client-2
  • タグ
  • トランク
    • インフラストラクチャ
    • project-for-client-1
    • project-for-client-2

このレイアウトにもいくつかの問題があります。ブランチは巨大になりますが、少なくともコード内の特定の場所にタグを付ける方が簡単です。

コードを使用するには、単にトランクをチェックアウトして作業するだけです。その場合、すべての異なるプロジェクトをチェックアウトするスクリプトは必要ありません。これらは、「../ Infrastructure」でインフラストラクチャを参照するだけです。このレイアウトの別の問題は、プロジェクトを完全に独立して作業する場合、複数のコピーをチェックアウトする必要があることです。そうしないと、あるプロジェクトのインフラストラクチャの変更により、別のプロジェクトも更新されるまでコンパイルされない可能性があります。

これにより、リリースが少し面倒になり、プロジェクトごとにコードが分離される可能性があります。

うん、うんざりだ。同じことをしますが、より良いレイアウトを考えることはできません。

つまり、Subversionに関連するすべてを自動化できる一連のスクリプトがあります。各顧客のプロジェクトには、 project.list というファイルが含まれます。このファイルには、その顧客の構築に必要なすべてのSubversionプロジェクト/パスが含まれます。例：

Infrastructure/trunk
LibraryA/trunk
LibraryB/branches/foo
CustomerC/trunk

各スクリプトは次のようになります。

for PROJ in $(cat project.list); do
    # execute commands here
done

コマンドがチェックアウト、更新、またはタグになる場合。それよりも少し複雑ですが、すべてが一貫していることを意味し、チェックアウト、更新、タグ付けは単一のコマンドになります。

そしてもちろん、できる限り分岐しないようにします。これは、私ができる最も重要な提案です。何かを分岐する必要がある場合は、トランクまたはできる限り多くの依存関係の以前にタグ付けされたバージョンのいずれかで作業しようとします。

まず、外見が悪であることには同意しません。完全ではありませんが。

現在、作業コピーを作成するために複数のチェックアウトを行っています。エクスターナルを使用した場合、これは正確に行われますが、毎回自動的かつ一貫して行われます。

ターゲットプロジェクト内のタグ（または特定のリビジョン）を外部に向ける場合、リリースごとに現在のプロジェクトにタグを付けるだけです（タグは、指している外部を正確に示すため）。特定のライブラリの新しいバージョンを使用するように外部参照を変更した正確なタイミングのプロジェクト内のレコードもあります。

外部は万能薬ではありません-投稿が示すように、問題がある可能性があります。外観よりも優れたものがあると確信していますが、（概念的にも）まだ見つかりません。確かに、使用している構造は、開発プロセスで大量の情報と制御を生成する可能性がありますが、外部を使用すると追加できます。しかし、彼が抱えていた問題は根本的な破損の問題ではありませんでした-クリーンgetはすべてを解決し、かなりまれです（実際にリポジトリにライブラリの新しいブランチを作成することはできませんか？）。

考慮すべき点-再帰的な外部を使用する。私はこれに賛成でも賛成でもないので、実用的なアプローチをとる傾向があります。

記事が示唆するようにピストンを使用することを検討してください。実際には動作していないので、実際にコメントすることはできません。より良い方法で外部と同じ仕事をするかもしれません。

私の経験から、個々のプロジェクトごとにリポジトリを持つ方が便利だと思います。そうしないと、あなたが言う問題があり、さらに、他のプロジェクトが変更されるとリビジョン番号が変わり、混乱を招く可能性があります。

ソフトウェア、ハードウェアスケマティック、ドキュメントなど、個々のプロジェクト間に関係がある場合のみ。リビジョン番号がパック全体を既知の状態にするために単一のリポジトリを使用します。

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