在Subversion的混合版本工作副本中查找錯誤

Question

我工作的項目最近已經從一個可怕的過時版本控制系統切換到了Subversion。我覺得我幾年前對Subversion有相當好的理解，但是一旦我瞭解了Mercurial，我就很快忘記了Subversion。

我的問題是針對那些在Subversion的同一分支上與大量（15+）開發者合作的人。

讓我們假設您檢出存儲庫的修訂版本N。你做了一些改變，然後提交。與此同時，其他開發人員對其他文件進行了更改。您聽說另一個開發人員對子系統X所做的更改，並決定立即需要它們。你不想更新整個工作副本，因爲它會引入各種各樣的東西，然後你將不得不做一個冗長的編譯（C++項目）。我看到的風險是，開發人員僅更新子系統X，但未意識到新代碼依賴於子系統Y中的最近更改。代碼編譯，但在運行時崩潰。

你如何處理這個問題？

• 開發者是否報告他們認爲可能是錯誤（即使它不是bug）？
• 您是否需要開發人員在報告錯誤之前更新其整個工作副本？這不會阻止錯誤報告嗎？
• 你是否通過一些我沒有想到的機制來防止這種情況發生？

Answer 1

由於您提交了所有正在進行的工作，因此您沒有理由不更新整個最新版本的副本。冗長的編譯是大型項目價格的一部分。編譯時間幾乎總是少於嘗試確定是否有bug的時間，或者是否因爲沒有檢查完所有內容而存在一些模糊的不兼容性。

該項目已將編譯分發到組中的所有工作站。由於我們有大約15臺計算機用於這項任務，這意味着通常需要6個小時左右的時間才能完成大約25分鐘。

Answer 2

追蹤依賴關係的責任是引入它的develloper。 在這種情況下，develloper X應確保更改與其他子系統的當前版本一起工作。或者至少記錄它與哪些版本協同工作。

我見過的幫助解決方案處理這個問題的方法是。

1. 在構建系統中包含依賴檢查。許多開源項目都是在.configure腳本中完成的。
2. 配置版本控制系統爲您處理。我不知道在顛覆中這樣做。

這顯然不是長時間的編譯時間，但它有助於避免不必要的重建。 複雜的依賴圖也是可疑設計的一個指標。重構代碼以減少子系統之間的耦合可能是個好主意。