我公司的產品是基於模塊的，這意味着我們配有五個基本模塊，用戶可以購買額外的模塊。我們使用的Mercurial是我們相對較新的源代碼管理產品，而且自從我們發佈了1.0版本的產品以來，管理單獨的模塊開發一直是一場噩夢。如何使用Mercurial管理產品的多個版本？
我們希望能夠在不必等待特定模塊開發完成的情況下發布小修補程序更新，因此，一切的回購並不能很好地工作。我閱讀了分支，但權威指南似乎表明分支是暫時的，並且與它合併很困難。
理想情況下，我們有一個基本回購是產品，然後是額外模塊的不同回購（或分支機構），這樣QA可以分別構建主要產品和主要+插件，而開發人員ModuleA不會影響使用BugfixB的開發人員。我嘗試過使用多個subrepos，但最終導致我的存儲庫被破壞。
我應該看看使用命名分支嗎？還是書籤？
我在尋找關於如何利用Mercurial功能使此過程更輕鬆的最佳實踐的建議。
謝謝！
有一個關於分支的好教程http://nvie.com/git-model。最主要的一點是要有
另外還有一個關於水銀分支的技術差異的參考文獻http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
我是Mercurial的新手，但我認爲你的問題並非特定於此。 您需要考慮釋放代碼和相關方的過程，並將此模型映射到可支持它的分支佈局。 Mercurial不錯，因爲它可以很好地支持開發人員，讓他們在不影響持續構建或其他下游流程（質量保證，安裝人員等）的情況下維護自己的開發「分支機構」。
[Rel]
^
[RC]
^
[QA]----[QA]------[QA]
^ ^ ^
[Dev] ---------------------------------------- -----------------
^ ^ ^
[Jen] [Paul] [Ken]
這是一個可能的方案，其中開發人員合併開發，有人定期合併到[QA]分支，當它烤好了去[RC]等。 每個版本都與其他活動保持隔離。
祝你好運！
這是一個典型的開發計劃。但是，它並沒有解決開發中同一產品的多個版本的問題。 – 2010-08-04 04:26:04
分支是您的解決方案。我認爲命名分支是一件好事。但是，您應該意識到命名分支機構需要一定程度的預見和使用紀律。
我會建議每個bug修復都有自己的分支。開發人員將分叉該分支，執行bug修復，重新合併到功能分支中。
我會考慮將你的模塊分成獨立的存儲庫，每個產品一個。可能這不是很有用;您必須查看不同的使用案例，並確定工作流程/編譯流程將如何實施。
我不明白爲什麼你會考慮有不同的subrepos這個時，文件歷史幾乎是相同的 - 這是分支機構的主要工作。唯一的麻煩是能夠爲每個分支挑選補丁 - 這可能需要您導出補丁（或補丁集）並將其分別應用到每個分支。這比它應該更尷尬，但它不會比在不同存儲庫中做同樣的事更難。
我認爲這個問題模糊了兩個不同的問題：
獨立的開發週期處理模塊化的產品，你應該使用不同的使用subrepos將每個模塊的存儲庫合併到一起，以適合每個客戶配置。看起來你已經在做這個，但是有腐敗問題。這當然是正確的方式，所以您需要從底部瞭解腐敗是來自Mercurial錯誤還是用戶錯誤。
爲了處理單獨的開發週期，我個人會去模塊克隆，但命名分支也可以。
希望這會有所幫助。
我們正在使用subrepos，但所有真正簡化的是目錄結構。我不確定每個模塊的產品完整副本的單獨回購最有意義。 – 2010-08-04 04:14:52
這個想法是，如果每個模塊都在一個subrepo中，您可以爲您正在使用的模塊提供最新版本的subrepo，並將模塊的其他subrepos留在最近的「穩定」狀態。同時主要產品在主目錄中，因此您可以隨時更新它。 – Amber 2010-08-04 06:40:04
對，這就是我們正在做的事情，但它不能很好地工作。回購是巨大的，每次他們克隆，他們變得更大。他們很容易腐敗。 – 2010-08-04 14:34:53