我們可以在同一時間得到雪藏了幾個星期的一些特性分支更新版本。在trunk中進行了很多更改之後，最好是將trunk中的更改合併到分支中，或者放下分支並直接從trunk中創建一個新分支，並將啓動分支中的更改複製到分支中。Subversion是否合併的差異或者只是在未修改的文件
的原因，我想問的是，對於合併SVN簡單地取行李箱的差異從去年合併到頭部和應用於的分支。
在很多情況下，樹幹的變化遠大於分支的變化，所以從差異的大小來看，刪除特徵分支並創建一個新的特徵分支變化被修補，將是有意義的。
當大量PDF文件被更新時，這是一個特別的問題。
這似乎是另一種方式將是SVN認識到，在一個分支文件從未接觸過，因此更新它指向的版本號，而不是盲目地運用差異。
從Subversion的輸出就好像它雖然應用diff文件。
從Subversion 1。6名更改文件：在倉庫
完全相同的文件共享的存儲空間（問題＃2286）
因此，看來，即使應用了差異，在提交時，代碼應該發現相同的文件，只是使用指針第一個版本的文件。
我覺得你使用Subversion的方式可能不正確（我之前已經這樣做了）。您需要做的是將一系列修訂合併到您的主幹中。 例子：
Rev: 100
/trunk
（做一個分支）
Rev:101
/trunk (r100)
/branch (r101)
（很多的變化）
Rev: 200
/trunk (r100)
/branch (r200)
現在你需要做的是生成所有R100與R200之間的差異列表並將它們應用於後備箱。合併有點誤導（like the documentation states）。您的使用案例是一種相當常見的情況，即covered in the documentation。
我不認爲有關於是否合併trunk->分支或科順>幹線任何的最佳做法。它非常依賴於你想如何工作和你的場景。從它的聲音中，特徵分支將更不穩定的主幹。一旦你完成了功能，合併到主幹將是有意義的。爲了限制當您重新合併到主幹時發生的衝突，您可以繼續從主幹 - >分支進行合併。
這似乎是另一種方式將是 SVN認識到，在 分支中的文件並沒有被感動，因此 更新的版本號指向 來。這將避免diff的額外空間 。
AFAIK，應用diff不會在顛覆中佔用任何顯着的額外空間。 如果差異很小，它應該只需要與更新修訂版本相似的空間量。
順便說一句，從樹幹合併到分支？只有當您計劃在稍後將分支合併回幹線時纔有意義。
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html