4

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

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

  • インフラストラクチャー
  • アプリ1
  • アプリ2
  • アプリ3
  • プロジェクト-クライアント-1
    • App1-プラグイン
    • App2-プラグイン
    • 構成
  • プロジェクト-クライアント-2
    • App1-プラグイン
    • App2-プラグイン
    • 構成

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

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

  • インフラストラクチャー
    • 枝
    • タグ
    • トランク
  • プロジェクト-クライアント-2
    • 枝
    • タグ
    • トランク

そして、同じことが残りのプロジェクトにも当てはまります。

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

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

SVN で上記のいずれかを解決する方法はありますか? クライアント プロジェクトで svn:externals を使用することを考えましたが、この投稿を読んだ後、それが正しい選択ではない可能性があることがわかりました。

4

5 に答える 5

3

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

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

于 2009-09-10T13:36:24.150 に答える
2

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

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

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

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

考慮すべきポイント-再帰的な外部を使用します。私はこれの「はい」または「いいえ」のどちらでも売られておらず、実用的なアプローチをとる傾向があります。

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

于 2009-09-10T14:29:15.183 に答える
2

ええ、それは最悪です。同じことをしますが、これ以上のレイアウトは考えられません。

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

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

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

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

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

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

于 2009-09-10T12:56:57.497 に答える
2

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

  • インフラストラクチャー
    • 枝
    • タグ
    • トランク
  • プロジェクト-クライアント-1
    • 枝
    • タグ
    • トランク
  • プロジェクト-クライアント-2
    • 枝
    • タグ
    • トランク

に

  • 枝
    • 機能-1
      • インフラストラクチャー
      • プロジェクト-クライアント-1
      • プロジェクト-クライアント-2
  • タグ
  • トランク
    • インフラストラクチャー
    • プロジェクト-クライアント-1
    • プロジェクト-クライアント-2

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

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

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

于 2009-09-10T13:13:48.217 に答える
0

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

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

于 2009-09-10T12:53:20.903 に答える