2012-06-01 63 views
7

我有使用Drupal,我有幾臺服務器,住,DEV1,DEV2 ......幾個站點在任何時候都保持git的鏡子同步

Drupal的代碼庫回購是大(112MB),所以我渴望充分利用git的硬連接能力,以便每次添加站點時都不會重複此操作。

等等,比方說,我有一個裸主回購的現場服務器,我的所有網站都是這個克隆,每個使用不同的分支。這在一臺服務器上很棒,使用硬鏈接,速度快,效率高。

但是在我的開發服務器上,它們通常都是從裸主回購站克隆的,這意味着同一臺計算機上的兩個站點不能使用硬鏈接來節省空間。

我想要做的是在我的每個開發服務器上設置裸露回購的鏡像,然後從中克隆。

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 hookgit push --mirror origin。現在,如果dev1上的site1推送提交,它們將被魔法推送到master-bare-repo。

但是如果我在現場服務器上做出改變,並推動?我不能設置post-receive鉤子推到其他(s),因爲這可能會觸發他們的post-receive掛鉤,這將最終在遞歸?

有沒有一些聰明的方法呢?

+1

後臺進程是否會定期嘗試從現場服務器工作(而不是後期接收)中拉出和推送?此外,嘗試一下,但我不認爲你會陷入與你的方法循環,​​因爲你第二次嘗試推動另一臺服務器沒有收到任何東西,因爲沒有什麼可推動的。 – Shahbaz

回答

4

首先,你不會以遞歸結束,因爲當「一切都是最新的」(如在this other question中指出的),後接收掛鉤不會被執行,這將是結果從鏡像推送到活動服務器。另一方面,這不是全部的可擴展設計(每次添加新鏡像時,都需要更改實時服務器的掛鉤以添加要推送的站點)。您可能會發現,在鏡像中使用「懶惰」同步策略會更優雅:當他們收到推送請求時,他們不會推送給主服務器,但在此之前他們會從主服務器中取/拉。這樣您就不需要在主設備中設置掛鉤,並且同步策略將完全由鏡像管理。這個策略的缺點是,你可能最終想要改變你想傳播到鏡像的活動服務器,然後他們需要推動任何改變。因此,您必須思考對您的主人進行的更改對於彌補可擴展性的權衡是如此重要。當然,正如評論中所建議的,使這種「可伸縮」設計也是「可同步」的補丁是通過使用外部cron作業來定期檢查master中的變化。

+0

這聽起來像它會工作!謝謝。一旦測試,我會給它一個答案並勾選答案。 – artfulrobot

相關問題