1

私たちは、いくつかのプロジェクトが使用する予定の社内フレームワークを開発しています。アイデアは、フレームワーク全体を各プロジェクトのリポジトリの水銀サブリポジトリとして追跡することです。これにより、次のサブレポ ツリーが作成されました (シンシェルリポジトリを参照)。

ProjectMaster/
    Project/
    CommonLib/
    FrameworkMaster/
        Framework/
        CommonLib/
  • これはあなたにとって意味がありますか？サブリポジトリを含まないこれらの依存関係を処理するためのより良い/より簡単な方法はありますか?
  • 具体的には、両方の CommonLib サブリポジトリを持つことは理にかなっていますか?
  • そうでない場合、Project が FrameworkMaster/CommonLib を使用することは理にかなっていますか? 依存関係がより複雑な場合、これは面倒になる可能性があります。
  • どこで機能ブランチを開きますか? マスターに？関連するサブリポジトリのみ？
    • マスターに機能ブランチがない場合、リポジトリを複製するたびに、最後のコミットのサブレポの状態を取得することになり、任意のサブレポが任意の機能ブランチに配置される可能性があります。非常に紛らわしいです。
    • マスターにフィーチャー ブランチがある場合でも、少なくとも 1 つのサブリポジトリにフィーチャー ブランチが必要です。

一般に、このソリューションは扱いにくいように思えます。助言がありますか？

4

1 に答える 1

2

シンシェルリポジトリのドキュメントの説明に従って：

For a thin-shell repository, all repositories containing 'real' code 
have no subrepositories of their own (ie. they are leaf nodes). They can 
thus be treated as completely ordinary repositories and a developer can 
largely ignore the additional complexities of subrepositories. Work can 
continue in these repositories even if their siblings become unavailable.

説明した結果の構造には、「実際の」コードを含むネストされたサブリポジトリがあるため、推奨される方法ではありません。Mercurial のドキュメントによると、推奨される構造は次のようになります (/FrameworkMaster/ がネストされたサブリポジトリの単なるプレース ホルダーとして含まれているのか、それとも「実際の」コードがあるのか​​はわかりません。/FrameworkMaster/ にも「実際の」コードがある場合)次に、兄弟リーフノードとして以下にも含める必要があります):

ProjectMaster/
    Project/
    Framework/
    CommonLib/

だから、あなたの質問に答えるために：

  • これはあなたにとって意味がありますか？サブリポジトリを含まないこれらの依存関係を処理するためのより良い/より簡単な方法はありますか?

シンシェル リポジトリを使用して、複雑な依存関係を簡素化することをお勧めします。

  • 具体的には、両方の CommonLib サブリポジトリを持つことは理にかなっていますか?

Project と Framework の両方が CommonLib の同じ バージョンまたはブランチに依存している場合、両方の場所に配置しても意味がありません。しかし、いくつかのレガシーな理由で、Project と Framework がCommonLib の異なる バージョンまたはブランチを必要とする場合、CommonLib を両方の場所に配置することは理にかなっています。

  • どこで機能ブランチを開きますか? マスターに？関連するサブリポジトリのみ？

ここでは、機能ブランチの意味がわかりません。ここで「未来」と言うつもりでしたか？

于 2012-12-10T05:54:15.347 に答える