Subversion是否合並差異或僅更新未修改文件的修訂版

Question

我們有一些功能分支，一次可以放幾個星期。 在主干中進行了許多更改之后，最好將主干中的更改合並到分支中，或者直接從主干中刪除分支並創建一個新分支，並將更改從起始分支復制到其中。

我問的原因是，對於合並，SVN只需從上一次合並到頭部之間獲取主干的差異，然后將其應用於分支。

在許多情況下，干線中的更改遠大於分支中的更改，因此從diff的大小來看，刪除特征分支並創建一個修補了特征分支更改的新分支是有意義的。

當更新許多PDF時，這尤其是一個問題。

對於SVN來說，似乎另一種方式是意識到分支中的文件從未被觸摸過，因此更新了它指向的修訂號，而不是盲目地應用diff。

從Subversion的輸出來看，似乎好像正在應用diff。

Answer 1

對於SVN來說，似乎另一種方式是意識到分支中的文件沒有被觸摸，因此更新了它指向的修訂號。 這樣可以避免diff多余的空間。

AFAIK，應用diff不會在Subversion中占用任何可觀的額外空間。 如果差異較小，則僅應占用與更新修訂版相似的空間量。

順便說一句，從主干合並到分支？ 僅當您計划稍后將分支合並回主干時才有意義。

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html

Answer 2

我認為您使用Subversion的方式可能不正確（我之前已經這樣做過）。 您需要做的是將一系列修訂合並到您的主干中。 例：

Rev: 100 
/trunk

（開店）

Rev:101 
/trunk (r100) 
/branch (r101)

（很多變化）

Rev: 200 
/trunk (r100)
/branch (r200)

現在，您需要做的是生成r100和r200之間的所有差異，並將它們應用於干線。 合並有點誤導（ 例如文檔說明 ）。 您的用例是一個相當常見的場景， 在文檔中進行了介紹 。

我認為關於合並trunk-> branch或branch-> trunk沒有最佳實踐。 這很大程度上取決於您的工作方式和方案。 從它的聲音來看，特征分支將更加不穩定。 完成功能后，將其合並到中繼中將很有意義。 為了限制合並回中繼時的沖突，可以從“中繼”->“分支”連續合並。

Answer 3

從Subversion 1.6 CHANGES文件中：

相同的文件共享存儲庫中的存儲空間（issue＃2286）

因此，似乎即使應用了diff，在提交時，代碼也應該發現相同的文件，並且僅使用指向文件第一個版本的指針。