SVN：衝突有多可靠？

Question

我必須從分支合併到主幹。這兩者在結構上有很大不同，有六十多棵樹有衝突，可能有五十多處文本衝突。可以理解的是，我對這次合併感到有些緊張。

我想知道生成衝突的準則究竟是什麼。假設一個函數F效率低下，所以分支開發人員重新編寫了一個輔助函數G，並且幹線中的開發人員以不同的方式重新編寫了它。在這種情況下，我知道在函數F上會產生衝突，函數F會被重寫爲兩種不同的方式。但是，是否會在功能G上產生衝突，該功能不屬於中繼版本？或者功能G實際上是否會被應用並逃避任何通知？我擔心這種混合可能導致的混亂代碼。

Answer 1

Subversion無法保護您免受語義衝突。對於這個問題，我不知道可以的版本控制系統。

在您的具體示例中，答案取決於。 G函數可能包含在衝突中。但是如果兩者在文件中分開的距離足夠遠並且G函數附近沒有其他變化，那麼合併將完全有可能仍然保持爲G.當然，還有許多其他方式可以獲得永遠不會有的語義衝突被版本控制系統所捕獲。例如說有人修改函數F來獲得一個新參數。另一個開發人員在另一個文件中添加了一個新的函數F調用，這個開發者改變了F並沒有觸及，他的工作副本也沒有改變。當開發人員提交新函數F時，即使語義上他的更改與存儲庫中的現有代碼衝突，也沒有衝突。通過我們今天使用的版本控制系統，解決方案是團隊溝通，代碼審查和測試。

避免像這樣的事情的唯一方法是如果合併工具理解語言，而不僅僅是面向行的衝突。這當然意味着您的版本控制工具需要支持您使用的每種語言。這會使其作爲一種通用工具而有用得多。

然而，有一種語義意識合併工具的實現。 SemanticMerge支持C＃和Java。 Subversion支持外部合併工具，我知道一些用戶已經使用這個工具來處理這些類型的案例。

在實踐中，這些問題實際上並不經常出現。