如何解決SVN樹沖突

Question

我已經閱讀了幾天，試圖找到一種使用tortiseSVN 1.8解決樹沖突的方法。 我的主干有兩個分支：

• 分支/ 3.1
• 支鏈/ 3.2

同樣，這兩個分支都不是主干。 我們不在主干上進行“主線”開發。 我正在嘗試將3.1分支的更改合並到3.2分支。

3.1中的代碼經過了一些重構，並且3.2分支中存在的許多文件夾在3.1分支中不再存在。 此外，還有一些新工作將新文件夾添加到3.2。 問題是樹沖突沒有給我解決沖突的方法，而只允許我接受工作副本。 這似乎是一個嚴重的缺陷。 我們正在進行大量的重構，我正在尋找一個過程，可以將早期版本分支上的更改集成到以后版本分支中。

有人可以告訴我最好的方法嗎？

Answer 1

要進行合並，您需要做兩件事：

• 您需要兩個分支之間有共同的血統。
• 如果您將兩個分支保持同步，則需要在兩個分支之間進行常規合並。 例如，我假設所有在3.1上的工作都應該在3.2中。 在兩個分支中都進行工作時，應該將3.1更改合並到3.2。

發生合並沖突是因為合並是一種三向比較。 將這兩個開發流（一個開發流可以引用一個分支或主干）相互比較，並將它們與最后一個共同祖先進行比較。 想象一個文件，在兩個開發流中都更改了第100行。 從一個合並到另一個將導致沖突。

Subversion不僅可以比較文件，還可以比較目錄。 如果我在一個開發流中重命名（或移動了一個文件）並進行了合並，則它將在另一個開發流中被重命名（或移動了）。 如果我在一個開發流中刪除或添加文件，然后合並，它也會在另一開發流中刪除或添加。

在Subversion中，如果我對兩個開發流中的同一文件執行兩項不同的操作，則可能會發生樹沖突 。 例如，我在3.1和3.2分支上都重命名了文件。 即使我使用相同的名稱重命名，Subversion也會將其視為沖突。

---

為防止災難再次發生：確保兩個分支確實具有相同的血統。 為什么不從3.1分支中分支3.2，或者至少在分支3.2之前將3.1分支重新集成到主干中。 Subversion通常非常擅長跟蹤歷史記錄，但是您需要確保分支共享相同的歷史記錄。

另一個是定期合並。 您需要定期將3.1合並到3.2分支-甚至每天。 這樣可以確保在3.2分支上工作的人員在3.1中具有他們所需的更改，並且不會重復所做的工作。 持續合並還可以使更改保持較小，並且當存在合並沖突時，它們更容易處理。 記住svn mergeinfo命令，該命令可以讓您知道已經合並到3.2中的內容以及在3.1上仍然需要合並的內容。 您始終可以使用--record-only參數來防止將來的合並考慮使用特定的修訂版。 例如，您修復了兩個分支上的錯誤，使用--record-only來確保對3.1的修復未對3.2進行。 或者，如果您在3.1中進行了更改，而您不想在3.2上進行更改，則執行--record-only將阻止您在下次合並時在3.2分支上考慮該更改。

---

現在做什么？ 您需要解開工作。 查看兩個分支之間的svn log 。 如果您看到兩個分支上都發生了錯誤修復，請使用svn merge --record-only來讓Subversion知道3.1分支上的特定更改也已在3.2分支上完成（盡管手動）。 查看文件移動和重命名，以及如何在每個分支上完成它們。

完成此操作后，一次將3.1到3.2的更改合並到幾個修訂版中，然后進行合並。 確保在3.2上需要對3.1進行更改。

這是一個漫長的過程，但是您需要完成它。 將其用作改進您的開發過程的課程。

---

我們曾經使用聽起來像您所使用的類似系統的東西。 Trunk被認為是原始的，並且與我們的發行版相匹配（從來沒有真正做到過）。 由於創建新分支以及將先前的分支合並到主干（或者只是丟失了從何處分支），我們一直在丟失從一個版本到另一個版本的更改。

分支就像孩子：您創造了一個分支，最好准備好照顧它，而不要迷失方向。

我們轉向了持續發展的過程 。 我們在主干上進行開發，然后在發布之前進行分支。 分支點通常在我們完成該版本的所有功能時出現，並且我們現在正在進行錯誤修復。

發布在分支上完成。 如果發現錯誤，則將在分支上修復該錯誤，然后僅將該修訂合並到主干（如果該錯誤也在主干上）。 發布完成后，分支將被鎖定。 如果我們需要做一個修補程序，我們可以將該分支重新用於該修補程序。

有時，我們有功能分支 。 當我們這樣做時，我確保我們不斷地從開發流合並到該功能分支。 這樣，當我們最終將該功能重新集成到主干中時，幾乎沒有沖突。

通過最小化分支並跟蹤我們從何處分支，並進行恆定合並（如在功能分支中進行合並），我們減少了合並沖突，並且不再遇到曾經困擾我們發行版的問題。