7

Drupal を使用するサイトがいくつかあり、ライブ、dev1、dev2 などのサーバーがいくつかあります。

Drupal のコードベース リポジトリは大きい (112Mb) ため、サイトを追加するたびにこれが重複しないように、git のハードリンク機能を最大限に活用したいと考えています。

たとえば、ライブサーバーには裸のマスターレポがあり、すべてのサイトはこれのクローンであり、それぞれが異なるブランチを使用しています。これは、ハード リンクが使用される 1 台のサーバーで優れており、高速で効率的です。

しかし、私の開発サーバーでは、通常、それらはすべてベア マスター リポジトリから複製されます。つまり、同じマシン上の 2 つのサイトがハード リンクを使用してスペースを節約することはできません。

私がやりたいのは、各開発サーバーに裸のレポのミラーを設定し、そこから複製することです。

dev1$ git clone --mirror live:master-bare-repo  dev1-mirror-repo
dev1$ git clone -b site1 dev1-mirror-repo site1
dev1$ git clone -b site2 dev1-mirror-repo site2

これまでのところすべて順調です。しかし、私はミラーが常に同期していることを望んでいます。そこで、dev1 のミラーでpost-receive フックgit push --mirror originを使用して. これで、dev1 の site1 がコミットをプッシュすると、それらは魔法のように master-bare-repo にプッシュされます。

しかし、ライブサーバーに変更を加えてそれをプッシュするとどうなるでしょうか? フックを設定しpost-receiveて他の人にプッシュすることはできません。これは、おそらく再帰的になるフックをトリガーするためですか? post-receive

これを回避する賢い方法はありますか？

4

1 に答える 1

4

まず第一に、「Everything is up to date」(この他の質問に記載されているように) の場合に post-receive フックが実行されないため、再帰に陥ることはありません。これは、からのプッシュの結果となります。ライブサーバーへのミラー。

一方で、それはスケーラブルな設計のすべてではありません (新しいミラーを追加するたびに、プッシュするサイトを追加するためにライブ サーバーのフックを変更する必要があります)。おそらく、ミラーで「遅延」同期戦略を使用する方がよりエレガントであることがわかるでしょう。プッシュを受信すると、マスターにプッシュするだけでなく、その前にマスターからフェッチ/プルします。この方法では、マスターにフックを設定する必要がなく、同期戦略はミラーによって完全に管理されます。この戦略の欠点は、ミラーが変更をプッシュする必要がある前に、ライブ サーバーに変更を加えてミラーに反映させたい場合があることです。そのため、スケーラビリティのトレードオフを補うために、マスターへの変更がそれほど重要になるかどうかを熟考する必要があります。もちろん、これを「スケーラブル」にするためのパッチ

于 2012-07-24T12:06:53.187 に答える