跟蹤子庫中的內部庫

Question

我們正在開發一個內部框架，有幾個項目將使用。 這個想法是將整個框架作爲每個項目存儲庫的subrepository進行跟蹤。這導致以下 subrepo樹（見thin-shell repository）：

ProjectMaster/ 
    Project/ 
    CommonLib/ 
    FrameworkMaster/ 
     Framework/ 
     CommonLib/ 

• 這是否任何意義嗎？有沒有更好/更簡單的方法來處理這些不涉及子庫的依賴項？
• 具體來說，有兩個CommonLib子庫是否有意義？
• 如果沒有，Project會使用FrameworkMaster/CommonLib嗎？如果依賴關係更復雜，這個 可能會變得混亂。
• 你會在哪裏打開功能分支？主人？只有在相關的 子庫？
  • 如果你沒有在主功能分支，每次克隆 庫你最終得到最後的subrepo狀態提交，而這對任何 在subrepo任何隨機特性分支。很混亂。
  • 如果您在主站上有功能分支，您至少需要在一個子報告中需要一個功能分支 ，以避免在那裏有未命名的頭部。

一般情況下，這種解決方案聽起來很困難的工作。有什麼建議麼？

Answer 1

按照描述的thin-shell repository文檔中：

For a thin-shell repository, all repositories containing 'real' code 
have no subrepositories of their own (ie. they are leaf nodes). They can 
thus be treated as completely ordinary repositories and a developer can 
largely ignore the additional complexities of subrepositories. Work can 
continue in these repositories even if their siblings become unavailable. 

你所描述所得到的結構具有嵌套包含「真實的」碼，因此其不推薦的方法subrepositories。根據mercurial文檔，推薦的結構如下（我不知道/ FrameworkMaster /是否只包含嵌套子庫的佔位符，或者它也有'真正'的代碼。如果/ FrameworkMaster /也有'真正'的代碼那麼它也應該包括在下面的兄弟葉節點）：

ProjectMaster/ 
    Project/ 
    Framework/ 
    CommonLib/ 

因此，要回答你的問題：

• 這是否任何意義嗎？有沒有更好/更簡單的方式來處理這些不涉及子庫的依賴關係？

更好/更簡單的方法是使用thin-shell存儲庫來簡化複雜的依賴關係。

• 具體來說，它是有意義的兼得CommonLib subrepositories？

如果這兩個項目和框架都取決於同一版本或分支CommonLib的那麼它是沒有意義的把它在這兩個地方。但是，如果由於某些遺留原因項目和框架需要不同版本或分支 CommonLib那麼它在兩個地方都有CommonLib是有意義的。

• 你會在哪裏打開功能分支？主人？只在相關的subrepository？

在這裏不確定你的意思是功能分支。你打算在這裏說'未來'嗎？