如何解決大型Subversion版本庫中的合併問題？

Question

在我解釋核心問題之前，讓我說我真的很感興趣將我們的源代碼控制從Subversion遷移到Git/Mercurial，如果它真的是我們問題的更好解決方案，但我真的很想找到最好的解決方案，而不會對團隊造成太多不必要的壓力。 （換句話說，我不是在尋找「完全轉儲顛覆，並移動到Git的」的答案，因爲這涉及到很多顛簸和陡峭的學習曲線。）

現在，這出的方式，這裏是我們的核心問題：

我的開發團隊正在處理一個相對較大的Subversion存儲庫，其中所有的開發過程都是直接在Trunk上完成的。來自上面的更快發佈週期的請求使我們將我們的工作分解成單獨的分支，每個分支包含創建分支時的Trunk鏡像和每個分支並行工作的子小組。新的週期是發佈一個特定的分支到生產環節，然後將新的更改合併到主幹中，並將主幹更改合併到其他分支中。

不幸的是，這已經成爲一個非常痛苦且容易出錯的過程，我們需要找到一種更好的方式來執行我們的合併，同時考慮到分支之間的簡單變化，例如代碼重新格式化（我們中有些人使用「清理代碼「在我們的源文件上，有些則不）。總而言之，我們需要幫助確定一種更好的合併方式，而不需要我們的一個或多個開發人員花一整天手動解決衝突。

（很抱歉，如果這是一個有點含糊或散漫，我會很樂意澄清或應請求提供更多的細節。）

Answer 1

看看Subversion的文檔在這裏：http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonpatterns.html

我的建議是使用功能分支合併模式將分支合併到trunk中。從一個人執行較少的變化/傷害開始。

新週期是釋放特定分支到生產，然後 合併的新變化到軀幹，和軀幹更改合併到每個 其它分支。

的特性分支合併格局，基本上顛倒順序進行這些操作。

補充說明：「清理代碼」是個好主意，只要大家在團隊使用它之前提交。 Subversion（或任何其他VCS）不可能知道哪些更改是代碼行爲，哪些更改是爲了美化。