多個機器的私人分支機構的Mercurial工作流程，服務於一箇中央回購機制

Question

我有一個svn回購機制，我想用Mercurial作爲它的前端。我一直在測試hgsubversion，看起來不錯。

我通常必須在編寫和測試代碼時在機器之間進行切換，並且希望能夠以我能得到它的方式檢查我的東西（在分支上，mq，還不確定）在其他機器上，在那裏編輯並推回等等，只有當我準備好將它推送到中央回購站時。

在混帳，我會做這與臨時私人分支，我會推動和拉我的機器之間。然後我重新回到主分支並推到中央回購站。但我仍然習慣於hg的完全不同的分支模型，並且我看不出哪個選擇最有意義（克隆，命名分支[它們是永久的？]，匿名分支，mq ...）

任何提示爲merntial新手？

Answer 1

僅對「中央」和「進行中」使用單獨的回購協議。讓你的核心，有意義的回購是推動你準備與世界分享變化的地方，直到你準備好發佈它們，把它們推到一個單獨的'-devel'回購。在所有機器上進行推拉操作，並在準備就緒時通過「推送」將其升級爲正式。

如果您不希望生成的變更集必須與您正在進行的變更集匹配，您可以更加友好並在devel中使用修補程序隊列（mq），但它本身受版本控制，但我是暴露的粉絲這個過程和結果一樣多，所以我不走那條路。

無論哪種方式，雖然推和拉都是你需要保持進行中的工作去/從一個-devel回購（或版本化隊列），然後當你準備好時，遷移到中央。

（該LocalBranch擴展在這個問題本身是不是所有你想要的東西，因爲他們沒有在機器之間的所有遷移評論所說 - 因此他們的名字。）

Answer 2

我最常做的是在Mercurial中使用書籤或本地創建的nambed分支。無論如何，本地命名分支在被推送到Subversion時將失去它的名字，並且書籤是暫時的。這可以讓你避免使用大量的倉庫，並保持清潔（呃）。

因爲在推送到Subversion時散列必然會發生變化，所以推動「背後svn的背後」可能會導致一系列稍微混亂的修訂。