4

これはSVN構造です：

/trunk
    + ProjectA
    + ProjectB
    + Common
        + ProjectCore
        + References

ProjectAそしてProjectB最終製品を提供し、それぞれが独自のリリース ライフ サイクルを持つことができます。両方のプロジェクトは、 の同じ共通ライブラリを使用しProjectCoreます。 ProjectCoreまた、独自のリリース ライフ サイクルがあります。ProjectAで、ProjectBのライブラリを参照したいと思いProjectCoreます。のリリース ライフサイクルが成功した後、ProjectCore-libs が SVN に追加されましたProjectCore。ProjectCore-libs がReferencesフォルダーに追加されます。

ProjectCoreこれにより、完全にテストされたコンポーネントとしてビルドをリリース (フリーズ) します。したがって、複数の Core-lib リリースがあります。

  • RLS_コア_1.00
  • RLS_Core_1.01
  • RLS_Core_2.00
  • RLS_Core_3.00

リリースされたライブラリ(dll)をSVNに追加し、ProjectA参照ProjectBできるようにしました。これを行うための最良のアプローチは何ですか？

アプローチ1

ProjectCore-libs を SVN のReferences名前付きの新しいフォルダーに追加しますRLS_Core_X_XX。

ProjectAとのソリューションではProjectB、この一意のフォルダへの参照を追加します: ./trunk/Common/References/RLS_Core_X_XX.

アプローチ 2

ProjectCore-libs を SVN の同じフォルダーの下に追加しますReferences/Core。その中に「古い」バージョンがあった場合、それはコミットになります。

とのソリューションでProjectA、ProjectBへの参照を追加します./trunk/Common/References/Core。SVN 外部プロパティを使用して、ProjectAおよびに使用する Core-libs のリビジョンを定義しますProjectB。

どちらのアプローチでも、開発者は自分のプロジェクト ソリューションでどの Core-libs リリースを使用するかを明示的に決定する必要があります。ルールは、機能が不足しているためにアップグレードする必要がない限り、同じ Core-lib を保持することです。 アプローチ 1 : プロジェクト ソリューションで編集します。アプローチ 2 : 外部プロパティで編集します。

どのアプローチが好ましいですか？

4

4 に答える 4

1

当然のことと思われる最初のことは、プロジェクトごとに推奨されるフォルダー構造（、、）フォルダーを個別に使用するbranchesことです。これは一般的なプロジェクトにも当てはまります。特に、これら2つの最終製品によって参照されるリリースがある場合はそうです。これらのプロジェクトは個別に開発されるため、個別のタグとブランチを作成できるはずです。tagstrunk

これを行ったら（そして、すべての参照をビルドされたアセンブリとして含める必要があるため）、リリースされたアセンブリを各プロジェクトのReferenceサブフォルダーに個別にコピーすることをお勧めします。

このように、ブランチを作成するときはいつでも、必要なバージョンの正確なスナップショットがあり、一般的なものの開発から独立しています。

言い換えると：

/RepoRoot
    + ProjectA
        + branches
        + tags
            + v1.0
            + v1.1
        + trunk
            + references (includes 3rd-party and ProjectCore)
    + ProjectB
        + branches
        + tags
            + v0.8
            + v1.2
        + trunk
            + references
    + ProjectCore
        + branches
        + tags
            + v2.0
            + v2.1
        + trunk
            + references
于 2012-02-28T10:51:53.787 に答える
0

異なるバージョン間での切り替えがより高速で簡単であるため、アプローチ 1 が気に入っています。

于 2012-02-28T10:48:13.767 に答える
0

どちらのソリューションもほとんど同じであるため、今すぐ展開を検討する必要があります。.NET アセンブリでバージョン管理が有効になっていると仮定すると、アプリを展開するときに正しいライブラリをリリースする必要があります。

したがって、私はそれを明示的にします-解決策1-libバージョン名を含むディレクトリを参照し、同じ参照ディレクトリを「再利用」しようとしないでください。その後、配信する dll のセットがわかるので、間違えることはありません。(これは、'use externals' オプションを使用せずにプロジェクトを更新した場合に実行できますが、これを行う人もいます。.NET では、誤って '間違った' dll で再構築すると、参照地獄の世界に陥ります)。

欠点は、更新時にプロジェクト参照を更新する必要があることですが、プロジェクト ファイル内を検索して置換する場合、これはそれほど問題ではありません。

于 2012-02-28T10:57:33.057 に答える
0

他の人がすでに言ったように、それはすべてまったく同じであり、十分に文書化する必要があります。しかし、トランク フォルダーのサブフォルダーという名前のバージョンとしてではなく、ProjectCore のリリースを配置することをお勧めします。代わりに、リリースごとにブランチを作成して、ProjectCore の下に次のような構造を取得します。

/RepoRoot
   + ProjectCore
   + trunk
       + ProjectCore
   + branches
       + RLS_Core_1_00
       + RLS_Core_1_01
       + RLS_Core_2_00
   + ProjectA
       + trunk
           + ProjectA
       + branches
           + ProjectA_3_57
           + ProjectA_3_78

ProjectA 内で ProjectCore の特定のブランチにリンクする ProjectA の下の外部フォルダーを使用して ProjectA 内で ProjectCore にリンクする場合、または .csproj ファイル内の参照パスをProjectA フォルダー構造の外(1 レベル上) に変更してリンクする場合は、好みの問題。

この回答は、開発者が subversion 外部プロパティの機能にどれだけ慣れているかにかかっています。彼らのほとんどがこれや正確にどのように機能するかを知らないと、混乱し、エラーにつながります。この場合、パスを .csproj ファイルに入れることで直接アプローチします。すべての開発者が外部を知っていて使用している場合は、これを使用してください。

于 2012-02-28T11:09:17.233 に答える