20

過去にHgサブレポの依存関係についていくつかの質問がありました（こことここ）が、受け入れられた回答は私にとって問題に対処していないようです.

私のプロジェクトには、A、B、C、D の 4 つの依存関係があります。D は A、B、C に依存しています。B と C は A に依存しています。

A、B、C、D の依存グラフ

Hg サブリポジトリを使用してそれらを保存し、それらが依存しているそれぞれのバージョンを追跡できるようにしたいと考えています。これは、このプロジェクトで A、B、C、および D を使用している間、他のプロジェクトでは A と B だけが必要になるためです。したがって、B と C は、D とは別に必要な A のバージョンを追跡する必要があります。同時に、私のアプリケーションでは、特定のバージョンの D によって参照される B と C のバージョンは、常に、D によって参照されるものと同じバージョンの A を使用する必要があります。 D の指定されたバージョン (それ以外の場合は、実行時にフォールオーバーします)。私が本当に望んでいるのは、それらが同じディレクトリ内の兄弟として相互に参照できるようにすることです。つまり、D の .hgsub は次のようになり、B と C は最初の行のようになります。

..\A = https:(central kiln repo)\A
..\B = https:(central kiln repo)\B
..\C = https:(central kiln repo)\C

しかし、これはうまくいかないようです: 理由はわかります (人々に首を吊るすのに十分なロープを与えるのは簡単でしょう) が、私の依存関係に対する最も適切な解決策だと思うので、それは残念です. いくつかの提案された解決策を読みましたが、それらについて簡単に概説し、それらがうまくいかない理由を説明します。

  1. ネストされたサブディレクトリとしてコピーを含め、これらを Hg サブリポジトリとして参照します。これにより、次のディレクトリ構造が生成されます (代わりに \D 内のコピーを参照することを受け入れることができるため、A、B、C、B\A、C\A のプライマリ コピーを削除しました)。

    • project\ (すべてのメイン プロジェクト ファイル)
    • プロジェクト\D
    • プロジェクト\D\A
    • プロジェクト\D\B
    • プロジェクト\D\B\A
    • プロジェクト\D\C
    • プロジェクト\D\C\A

    このアプローチの問題:

    • 現在、ディスク上に A の 3 つのコピーがあり、そのすべてに独立した変更が含まれている可能性があり、中央リポジトリにプッシュする前に同期およびマージする必要があります。
    • B、C、および D が同じバージョンの A を参照していることを確認するために、他のメカニズムを使用する必要があります (たとえば、D は v1 を使用し、D\B は v2 を使用できます)。

  2. バリエーション: 上記を使用しますが、親コピーのコピーを指すように .hgsub の RHS を指定します(つまり、B と C には以下の .hgsub が必要です)。

    A = ..\A

    このアプローチの問題:

    • ディスクにはまだ 3 つのコピーがあります
    • 初めて B または C を複製すると、参照されているバージョンの A を "..\A" から再帰的にプルしようとしますが、これは存在しない可能性があり、おそらくエラーが発生します。存在しない場合、レポがどこにあるのかについての手がかりが得られません。
    • 変更を再帰的にプッシュすると、D\B\A の変更が共有の中央レポに反映されません。代わりに D\A にプッシュされるだけです。したがって、2 回続けてプッシュすると、すべての変更が正しく反映されることを保証できますが、これはかなりの間違いです。
    • 同様に、(手動で) 再帰的なプルを行う場合、最新の変更を取得するために正しい順序を取得する必要があります (つまり、D\B\A をプルする前に D\A をプルします)。

  3. シンボリックリンクを使用して、フォルダー \D\B\A を D\A などにポイントします。

    このアプローチの問題:

    • シンボリック リンクは Hg リポジトリ自体でエンコードできないため、チーム メンバーがリポジトリを複製するたびに、手動またはスクリプトを使用してシンボリック リンクを再作成する必要があります。これは許容できるかもしれませんが、より良い解決策を希望します。また (個人的な好み) シンボリック リンクは非常に直感的ではありません。

これらは利用可能な最善のソリューションですか? 私の最初の .hgsub (上を参照) が夢物語である正当な理由はありますか、またはこの変更を要求/実装する方法はありますか?

A、B、C、Dのより広い使用法をよりよく説明するために更新されました

4

2 に答える 2

5

Mercurial を介して (またはその点で任意の SCM を使用して) 依存関係を管理しようとする代わりに、代わりにApache Ivyなどの依存関係管理ツールを使用してみてください。

Ivy ベースのアプローチを使用すると、サブリポジトリはなく、プロジェクト A、B、C、D だけになります。A はアーティファクト (.jar、.so、.dll など) を生成します。アーティファクト リポジトリ (基本的には、ビルド アーティファクトを保持する場所) にバージョンとともに公開されます。プロジェクト B と C は、Ivy がアーティファクト リポジトリから取得する A の特定のバージョン (各プロジェクトの ivy.xml ファイルで制御) に依存することができます。プロジェクト B と C は、リポジトリに公開されるアーティファクトも生成します。プロジェクト D は B と C に依存しており、Ivy は依存関係を推移的に取得するように指示できます。つまり、B、C、および A のアーティファクトを取得します (これらは A に依存しているため)。

Apache MavenとGradleで同様のアプローチを使用できます(後者は Ivy を使用します)。

主な利点は次のとおりです。

  • プロジェクトが使用している各コンポーネントのバージョンが非常に明確になります (チェックするのを忘れて.hgsub、サブリポジトリで作業していることがわからない場合があります)。
  • 依存プロジェクトを変更できなくなります (コードではなくアーティファクトで作業しているため)
  • また、依存プロジェクトを再構築する必要がなく、使用しているバージョンがわからないこともありません。
  • 他のプロジェクトで使用されるプロジェクトの複数の冗長コピーを保持する必要がなくなります。

編集: Mercurial と Eclipse を使用した Project Feature Sub-Modules のベスト プラクティスで、わずかに異なるスピンを持つ同様の回答?

于 2011-09-26T14:40:52.200 に答える
2

それぞれがどのバージョンに依存しているかを追跡したいとしますが、B、C、D の間で共有される A の単一のコピーでも満足するでしょう。これらは相互に排他的です。A の単一のコピーでは、A への変更B、C、D のそれぞれの .hgsub が変更されるため、バージョン管理に独立性はありません (B、C、D のすべてが A への変更後にコミットされるため)。

別々のコピーを持つことも厄介です。A の B のコピーと C のコピーの両方に影響する変更を加えてから、構造全体をプッシュしようとすると、(たとえば) B への変更は成功しますが、C への変更は、プッシュしたばかりの変更とマージする必要があるため失敗します。 B、新しい頭の作成を避けるため。そして、それは苦痛になります。

私がこれを行う方法 (そしておそらくもっと良い方法があるかもしれません) は、A、B、および C のサブリポジトリを含む D リポジトリを作成することです。 post-clone hookを介して入力し、ビルド システムに A リポジトリを探す場所を指示します。これには機能するという利点がありますが、{B, C} と A の同時バージョンを追跡するシステムの利便性が失われます。繰り返しますが、フックによって更新された B または C のそれぞれにある A バージョン ファイルを使用して手動でこれを行うことができます。 、フックで読み取ると、それを機能させることができますが、hg. 私の提案は、要約すると、独自の単純化されたサブレポ システムを実装することです。

于 2011-04-12T23:50:41.787 に答える