現在、私はレガシーバージョン管理システムから移行し、グループのプロジェクトをMercurialに移行しています。移動するコードの種類の一例として、25以上のプロジェクトのVisual Studioソリューションがあり、すべて共通のコードに依存するいくつかの個別のアプリケーション領域が含まれています。Stack Overflowを見ると、私が見つけた最も近い質問はこれでしたが、バージョン管理についてのみ言及していました。Mercurialを使用してこれらの依存関係を管理する特定の実装手法について、もう少しアドバイスを探しています。

依存関係の簡略化されたビューは、次のようになります。（これは説明と例にすぎません。実際の依存関係はかなり複雑ですが、本質的に類似しています。）

Common Libモジュールは共有コードになります-これは、コンパイル時と実行時の両方で、すべてのアプリ間で同時に使用されるDLLまたはSOまたはその他のライブラリになります。そうでなければ、アプリケーションは互いに独立して実行できます。

Mercurialリポジトリの設定にはいくつかの目標があります。

• 重要な各アプリケーションまたはコンポーネントグループに独自のリポジトリを提供します。
• 各リポジトリを自己完結型にします。
• プロジェクトの合計を自己完結型にします。
• コードベース全体を一度に簡単に構築できるようにします。（最終的に、これらのプログラムとライブラリはすべて1つのインストーラーになります。）
• 単純にする。

もう1つのポイントは、これらのプロジェクトごとに個別のリポジトリがあるサーバーをセットアップしていることです。

これらのプロジェクトをレイアウトする方法はいくつかあります。

1.すべてを含む「シェル」リポジトリを作成します。

これは、URLベースのサブリポジトリを使用します（たとえば、.hgsubでは、次のようにします）。レイアウトすると、次のようになります。App1 = https://my.server/repo/app1

シェルリポジトリの各メインフォルダには、プロジェクト領域ごとに1つずつサブリポジトリが含まれます。依存関係は相対的です。たとえば、App4はCommonLib 2を必要とするため、相対パスを使用してその共通ライブラリを参照します。

このアプローチの長所：

• 各ライブラリは一度だけプルダウンされます。
• Mercurialのサブレオは、同じバージョンのライブラリがすべてのプロジェクトで自動的に使用されるようにします。これは、そのサブリポジトリの1つのバージョンのみがプロジェクトに存在するためです。
• 各リソースを見つけるのは簡単です。

このアプローチの短所：

• アプリを単独で操作することはできません。たとえば、アプリ2で作業していて、共通ライブラリを変更する必要がある場合、他のすべてのアプリは今すぐそれらの変更を行う必要があります。
• アプリリポジトリを単独でプルする場合、それを構築する場合は、他にどのような依存リポジトリが必要かを手動で把握（または把握）する必要があります。
• 依存関係は強く分離されていません。すべての機能を簡単に取得できるため、どこにでも新しい機能を挿入したくなるでしょう。

2.依存するサブリポジトリを完全に封じ込めます。

このアプローチでは、各アプリケーションは（以前と同様に）独自のリポジトリを持ちますが、今回はサブリポジトリも含まれます。1つは独自のソース用で、もう1つは依存するサブリポジトリごとです。全体的なリポジトリには、これらの各プロジェクトリポジトリが含まれ、ソリューション全体を構築する方法がわかります。これは次のようになります。

長所：

• 各アプリケーションは、互いに独立して、単独で構築できます。
• ライブラリの依存バージョンは、グローバルではなく、アプリごとに追跡できます。新しい依存関係を追加するには、プロジェクトにサブリポジトリを挿入するという明示的な操作が必要です。

短所：

• 最終ビルドを行うとき、各アプリは異なるバージョンの共有ライブラリを使用している可能性があります。（一般的なlibサブリポジトリを同期するためのツールを作成する必要があるかもしれません。Eww。）
• ソース全体を構築したい場合は、共有ライブラリを複数回プルダウンすることになります。Common Lib 1の場合、8回（！）プルする必要があります。

3.依存関係をサブリポジトリとして含めないでください-ビルドの一部としてそれらを取り込みます。

このアプローチは、共通ライブラリがビルドの一部としてのみプルされることを除いて、アプローチ1とよく似ています。各アプリは、必要なリポジトリを認識し、それらを共通の場所に配置します。

長所：

• 各アプリはそれ自体で構築できます。
• 共通のライブラリは一度だけプルする必要があります。

短所：

• 各アプリで現在使用されているライブラリのバージョンを追跡する必要があります。これはサブレポ機能を複製します。
• これをサポートするインフラストラクチャを構築する必要があります。つまり、ビルドスクリプトにさらに多くのものを投入する必要があります。うーん。

4.他に何がありますか？

それを処理する別の方法はありますか？より良い方法は？どのように試みて成功しましたか、どのように試みましたが嫌いでしたか？私は現在1に傾いていますが、アプリケーションの独立性の欠如は、それが可能であるはずなのに、本当に私を悩ませています。（オプション3のように）それを処理するためのスクリプトを書く必要がなく、大規模な重複コードのプルと依存関係の維持の悪夢なしにメソッド2をうまく分離する方法はありますか？

サブリポジトリのURLの1つが変更され、新しい場所を使用するためにすべてのプロジェクトを更新する必要がありました。そのサブリポジトリを使用するすべてのプロジェクトの作業用クローンがあります。

しかし、そのうちの1つの作業コピーがなかった場合、そのプロジェクトのクローンを作成してそのサブリポジトリURLを更新するにはどうすればよいでしょうか。作業コピーなしで.hgsubに変更することは可能ですか？

それをする方法がないようです...

私のリポジトリには、使用しているモジュール用のサブリポジトリがいくつか追加されています。私は常にこれらのサブリポジトリを「プルのみ」として扱います。それらに変更を加える予定はありませんが、新しいバージョンがリリースされた場合に新しい変更を簡単にプルできる機能を保持したいと考えています。

メイン リポジトリをプッシュすると、Mercurial はサブ リポジトリをプッシュしようとします。これを防ぐ設定はありますか？

私たちの小さなオフィスでは、Mercurial をセットアップしています。「本物の」バージョン管理システムを使用するのは初めてです。ライブ サーバー、ステージング サーバー、開発サーバーの 3 つのサーバーがあります。

また、訪問者用、ユーザー用、オフィス スタッフ用のイントラネット サイトの 3 つの比較的大きな Web サイトもあります。

3 つの Web サイトは、一部のコードを共有しています。(たとえば、php クラス ライブラリ、一般的に使用されるコード スニペットなど)

バージョン管理の前は、シンボリック リンクを使用して共有ライブラリにリンクしていました。たとえば、各サイトには「ObjectClasses」ディレクトリへのシンボリック リンクがありました。ObjectClasses 内のファイルに加えられた変更は、すべてのサイトで即座に利用できます。変更したファイルをステージングとライブにアップロードするだけで完了です。

しかし... Mercurial はシンボリック リンクをたどりません。そこで、3 つのサーバー上の 3 つのサイトに共有ライブラリ用のサブリポジトリをセットアップしました (開発サーバー上にリポジトリの 2 つの別個のクローンを持つ 2 人のプログラマーがいるという事実を数えると、実際には「4 つの」サーバーです)。

したがって、共有オブジェクト ライブラリの 12 個の作業コピーがあります。

だからここに質問があります：

上記の設定を簡素化する方法はありますか？

これは私たちのワークフローがどうなるかの例で、複雑すぎるように見えますが、これはバージョン管理を使用するようなもので、慣れる必要があるだけかもしれません:

プログラマー A は、サイト 1 のサブレポにあるオブジェクト Foo に変更を加えます。プログラマー A は、これをどこでも利用できるようにしたいので、それをコミットし、ステージング サーバーにプッシュします。ステージング サーバーにフックを設定して、ステージング サーバー上の 3 つのサイトに変更を自動的に伝達し、ライブ サーバー上の 3 つのサイトに再度伝達します。これにより、ステージング サーバーとライブ サーバー上の 6 つの作業コピーが処理されます。ここまでは順調ですね。

しかし、これらのファイルで進行中の作業がある可能性がある開発サーバーはどうですか?

プログラマー A は、共有サブレポを開発サーバーのサイト 2 と 3 に手動でプルする必要があります。彼はまた、プログラマー B に、サイト 1、2、および 3 の共有サブレポを、開発サーバー上の自分のサイトのコピーで手動でプルするように指示する必要があります。彼がサイト 1 で Object Foo を編集し、サイト 2 で Object Foo に別の編集を行っているとしたらどうなるでしょうか。彼は 2 つの別々の競合を解決する必要があります。

比較的頻繁にオブジェクトに変更を加えます。これは私たちを狂わせるでしょう。私はバージョン管理のアイデアが大好きです。しかし、最適なセットアップを見つけようと 2 週間格闘した後、共有ファイルのコピーを 1 つ持っていて、「やあ、そのファイルで作業しているんだ。 a change」は今のところかなり良さそうです。

これを設定する簡単な方法は本当にありませんか？

メインの親リポジトリにタグを付けて、そのタグをすべてのサブリポジトリにも追加することはできますか?

これがないと、プロジェクトをサブリポジトリとして削除して単独でアクセスすると、これは親リポジトリにのみ属しているため、すべてのタグ情報が失われます。

SVNサブリポジトリを含むMercurialリポジトリがあります。hg updateMercurialは、ファイルの処理中にフリーズします.hgsubstate。これは、MercurialsvnがSVNの正しいリビジョンをプルするコマンドをバックグラウンドで実行するためだと理解しています。

SVNサブリポジトリーは非常に大きく、全体がハングしているように見えるため、ユーザーにとっては非常に直感的ではありません。

そのような操作中にsvn出力をダンプする方法はありますか？

3 つのサブフォルダーがあるリポジトリがあります。
A、B、およびコア フォルダー。

AとBにコアフォルダーのファイルが必要です。したがって、コアフォルダーのすべてのファイルはAとBの別のフォルダー内にある必要があり、ファイルへのすべての更新は「コア」にコミットされ、その逆も同様です。
そこで、コアフォルダーをサブリポジトリにして、これを A と B に追加しようとしました。

たとえば、フォルダー B には、.hgsub に次の行がありますwww = ../core
。メイン リポジトリは .hgsub にあります。core = core

私が間違っていることがあると思いますが、私が望むものを達成する方法のヒントがあるかもしれません:)

（更新）
明確にするために：
リポジトリには、アプリのさまざまな「プロジェクト」が含まれています。
A は Android、B は iOS です。「コア」には、後で Android および iOS プロジェクトで phonegap を使用してアプリを構築するために使用される HTML+JS ファイルが含まれています。

次のように2つのサブリポジトリが設定されたリポジトリがあります。

マシンAで、プロジェクト、www、およびdevをチェックアウトし、.hgsubをそのように変更しました。wwwおよびdevサブリポジトリがhg（commit -Sなど）によって認識されるようにするには、これをコミットする必要があります。

ただし、マシンBはプロジェクトのwww機能のみを使用するため、次のようになります。

繰り返しますが、マシンBの.hgsubにはwwwのエントリしかありません。これを、hgがサブリポジトリとして認識するためにコミットする必要があります。

私がやりたいのは、中央リポジトリにプッシュアンドプルすることですが、.hgsubをプッシュ/プルしないでください。それ以外の場合、マシンAから.hgsubをコミットしてプッシュし、マシンBからプルすると、不要なwwwサブリポジトリだけでなくdevサブリポジトリも自動的に取得されます。

そこで、マシンBで.hgsubを再度変更して、wwwのみを取得し、それを有効にするためにコミットします。マシンBのwwwサブリポジトリでいくつかの作業を行い、中央リポジトリにプッシュバックしたいのですが、.hgsubへの変更もプッシュされます。マシンAを引っ張ると、「dev」サブリポジトリがなくなり、.hgsubに再度追加する必要があります。このように、欲求不満で髪を抜くまで前後に移動します。

これを回避する方法はありますか？.hgsubは、サブリポジトリが機能するために各マシンでローカルにコミットされる必要がありますが、プッシュまたはプルされたくありません。プッシュ/プル用の.hgignoreはありますか？

乾杯。

Mercurialサブリポジトリに関するすべての質問を読みましたが、それがどのように機能するかはまだわかりません。IISでhgweb.cgiを使用しているため、すべてのリポジトリへのhttp：//パスがあります。

基本的なレイアウトは次のとおりです。

.hgsubファイルでは、パスを次のように設定しています。

プロジェクトで作業したい場合は、サーバーからワークステーションにクローンを作成して、Project1とProject2のクローンを作成すると、サブリポジトリも自動的にプルされます。

ローカルワークステーションのproject1で、/ Project1/LibrariesSubrepo内のファイルにいくつかの変更を加えます。これらの変更がサーバー上のライブラリのソースリポジトリに戻るようにするにはどうすればよいですか？サブリポジトリからサブリポジトリのソースリポジトリに変更を手動でプッシュする必要がありますか？

Project1リポジトリでローカルに変更を加え、それらの変更をコミット/プッシュできるようにしたいのですが、Project2では、サーバーから変更をプルして、Project2/LibrariesSubrepoを最新バージョンに更新できるようにする必要があります。

TortoiseHg2.1.3およびHg1.9.2を使用します。私が何をしても、親リポジトリは、最初にサブリポジトリでコミットしない限り、サブリポジトリで作成された新しいファイルを認識しません。すべてのコミットとプッシュは親リポジトリでのみ実行されることになっていると思いましたか？