26

クライアントの SourceSafe リポジトリ (3 つのプロジェクト) を SVN に移行していますが、そのうちの 2 つのプロジェクトがソース ファイルを共有しています。(これらのプロジェクトは別の製品であり、名前やリリース バージョンなどが異なります)

SVN はこの欠点を解決しましたか? 人々は一般的にこのシナリオをどのように処理しますか?

私が知っている/考えられる選択肢のうち

  • SVN には、external または extern などを使用します。これはさまざまな理由で良い選択肢ではないと聞きました

  • ソースを含む新しいプロジェクト (おそらく共有と呼ばれる) を作成します。これに関する問題は、そのコード (ライブラリではない) を取得し、何らかの方法でプロジェクトにインポートする必要があることです。上記の問題と同じ問題であることが示され、追加の製品/プロジェクトのオーバーヘッドが発生します。

  • 両方のリポジトリでファイルをチェックインし、相互更新するだけです。これには、開発者が共有について知り、チェックインを忘れないようにする必要があります。既知のすべての共有ファイルをチェックし、必要に応じて更新するスクリプトを作成できると思います。

  • 共有する 2 つのプロジェクト用に 1 つのリポジトリを用意します。これにより、2つを含むトップレベルのプロジェクト/リポジトリを作成する必要があり、ラベル付けの問題が発生します。トップ疑似プロジェクトにラベルを付けたくありません。(タグ、トランク、ブランチは、私が望む場所に正確にはありません。)

私はおそらく最後のオプションを使用します。

他にコメントはありますか？

4

8 に答える 8

9

svn:externals について正確に何を聞いたかはわかりませんが、ここではそれを使用する必要があると思います。共有ソースの安定版ブランチまたはリリース タグを指すように外部を指定することも、それを使用する他の 2 つのプロジェクトからの 2 つの異なるタグを指すこともできます (共有コードのバグをできるだけ早く修正する場合は、これが必要になる場合があります)。プロジェクト A の場合、プロジェクト B で完全にテストするのに十分な時間がありません)。

最悪の事態は、オプション 3 (同じファイルの 2 つのバージョンを相互更新する) です。

于 2008-09-25T19:32:33.363 に答える
6

これを行う安全な方法は、共有ソースを他の 2 つのプロジェクトで使用されるライブラリにビルドする 3 つ目のプロジェクトを用意することです。ライブラリ プロジェクトには、独自の SVN リポジトリがあります。

ヘッダーだけの共有ファイルでもこれを行うことができます。それらを lib プロジェクト ディレクトリに残して、インクルードのリストに追加するだけです。

2 つのプロジェクトに同じファイルがあると、ソース コントロールを使用しても、遅かれ早かれ問題が発生します。

于 2008-09-25T19:28:57.600 に答える
5

誰かがこの質問をグーグルで検索し、TortoiseSVNで外部リソースをどのように紹介するのか疑問に思った場合に備えて、ドキュメントは次のとおりです。

共通のサブプロジェクトを含める

外部アイテム

于 2011-03-17T09:43:36.613 に答える
2

もちろん、1つのリポジトリを使用します。後でもっと共有コードがあるかもしれません。

タグ付けの問題は正確には何ですか？したがって、タグに追加のフォルダーがありますが、スペースのコストはかかりません。その余分なフォルダが本当に必要ない場合は、ツリーを整理するためのアイデアを次に示します。

  • /
    • トランク
      • prj1
      • prj2
      • 共有
    • タグ
      • tag1
        • prj1
        • 共有

つまり、prj1にタグを付ける場合は、tag1を作成してから、prj1をコピーして共有します。

于 2008-09-25T19:44:57.840 に答える
1

使用している言語やビルド ツールについては触れていませんが、Java プロジェクトの場合、Maven を検討する価値があるかもしれません。機能の 1 つは、本質的に ant を拡張して、外部依存関係を取り込めるようにすることです。これにより、メタ プロジェクトを作成、維持、およびラベル付けする必要があるという懸念が解消されます。また、外部プロジェクトの HEAD からプルするか、特定のタグからプルすることもできます。これにより、プロジェクト間で共通ファイルを共有し、誤って破損を引き起こすという以前の投稿者による懸念の 1 つが軽減されます。これは、各プロジェクトがいつ使用するかを制御できるためです。共有ファイルの新しいバージョンを個別に。

于 2008-09-25T20:57:07.027 に答える
1

私の経験では、2 つの独立したプロジェクトが同じソース ファイルを参照するのは問題があります。これは、一方のプロジェクトのニーズを満たすために共有ファイルのコードを追加または変更して、もう一方のビルドを壊してしまう可能性があるためです。

ここでの秘訣は、各プロジェクトが独立して進行できるようにすることのようですが、必要なときにのみ変更されるように、共有コードを安定させたいリポジトリを設定します。

たとえば、共有コードが同じリポジトリの 2 つのブランチ/フォルダーにある場合、または 2 つの異なるリポジトリに別々にチェックされている場合、または 3 つ目のリポジトリに単独で存在している場合は、そのコードをアップグレードする手順が必要です。副作用がなく、分離、デバッグ、およびバグ修正できる手動のものであること。

このコードを 3 番目のリポジトリに分割し、内部のリリースおよびアップグレード手順として、そのコードを依存プロジェクト リポジトリに定期的に移行します。私の個々のプロジェクトには、「Shared.App.dll の v4.3.345 にアップグレード」のようなリビジョンがあり、そのバージョンに対して動作するために必要なすべての変更が含まれています。

共有コードが 2 つの依存プロジェクトと同じリポジトリの一部である場合は、プロジェクトごとに個別のコピーを作成し、リポジトリ マージを使用して変更を反映します。

于 2008-09-25T19:26:02.660 に答える
0

共有する 2 つのプロジェクト用に 1 つのリポジトリを用意します。これにより、2つを含むトップレベルのプロジェクト/リポジトリを作成する必要があり、ラベル付けの問題が発生します。トップ疑似プロジェクトにラベルを付けたくありません。(タグ、トランク、ブランチは、私が望む場所に正確にはありません。)

他の人と同じように、私は確かに最後の方法でそれを行います. 「たった」1 つのリポジトリを持つことのどこが悪いと思いますか? リポジトリは管理者権限に関するものです。それ以外では、単一のレポに N 個のプロジェクトが含まれていることがわかります。

于 2008-09-25T19:31:18.857 に答える
0

トリガーを使用してファイルを更新するのは悪い考えのように思えます。どういうわけか、それらは同期から外れます。共有コードを使用した実際の解決策は、コードをライブラリに抽出し、そのライブラリを複数のソリューションで使用することです。ただし、それはプロジェクトの範囲外のように聞こえるため、最後の解決策が最善の策です。

于 2008-09-25T19:25:29.493 に答える