在大型專案使用版本管理工具 Using source control tools on huge projects

「...在重啟 Longhorn 專案之前，他們大約有七個分支（譯註：branches，是版本管理工具常會提供的功能之一，可以將目前管理的專案發展出多個支線，每個支線可各自發展，卻又保持有所關連。），然後大約每二或三週，將這些分支整合回主要分支上。現在，想像有數千個開發者將他們的程式碼直接提交（譯註：check in，將開發者修改的部分程式碼上傳到版本管理伺服器）到這七個分支上，會導致以下兩個狀況：

「1.你頻繁的提交程式碼，這很容易導致現有版本無法編譯，或者作業系統功能有問題； 2.相反地，假若你沒有常常提交程式碼（這明顯是很糟糕的事），會讓你無法良好地回溯追蹤修改歷史。

「這明顯地不具有彈性。因此重啟專案之後，我們決定每個團隊應該要有他們自己的功能分支，每個「功能分區」（跨多個團隊）會再彙整成一個支線，最後整合成最終的主要支幹。（因此目前有上百個分支，分屬於大約六個支線之下）各團隊可自由地選擇他們需要的分支，並且可自由地決定上傳修改部分到支線的頻率。回歸整合（譯註：reverse-integration, RI, 意思是將修改的內容彙整回主要支幹）需要通過多種品質鑑定，像是效能測試。視評量關卡的多寡而定，至少會花掉一天的時間來進行這整個流程，再加上一兩天的時間應付突發狀況，所以進行一次 RI 需要相當的成本。然而，這些評量關卡都是為了確保主要支幹上的產品的品質，如果沒有這些關卡，這套作業系統大概永遠無法推出。我認為這是那種「不會害死你」的交易(譯：代價有點高但還是值得做)。

「有些團隊的確以用不健康的方式來進行專案，像是數個月才 RI 一次，但這是這些個別團隊的問題（或者說是他們的發佈管理），而不是流程的錯。一般來說，在品質方面越有紀律的團隊，其 RI 的頻率會更快更頻繁。從你獲得的系統元件穩定度/品質等級的變化資訊，可以輕易的推測出 RI 的速度等等，這是因為這些事情都是緊密的相連在一起。