什麼決定了SVN 1.6合併操作的速度

Question

我很驚訝合併從任何特定分支到樹幹的非常小的變化需要多長時間; 1-2分鐘合併幾行文本，這些文本在僅有2k長的單個文本文件中發生了變化。

我想，如果可能的話，合併快很多地獄，但不知道從哪裏開始。我做了一個快速谷歌和慢合併的可能原因似乎包括任何和所有的以下內容： -

• 大尺寸回購（包括對磁盤和修訂的數量規模而言）。
• 大源樹（顯然SVN具有抓取下來的樹，以制定出變化）
• SVN服務器/客戶端的版本
• 非常大（幾MB）的文件（我們沒有非常大單個文件，所以我懷疑這會影響我們）

我想我真的想知道如何找出上述哪些點合併如此緩慢。

現在我處於黑暗中，無論是在客戶端上工作還是在花費最多時間的服務器上工作（以及我懷疑它是客戶端，因爲服務器上的CPU使用量不是很大）。我確實認爲這可能是大量的合併信息累積了超過100年的合併，但我已經做了一個測試，我已經從幾個分支中刪除了所有合併信息，然後進行了合併並發現相同的緩慢。我想問的是： - *如何診斷/分析SVN活動？ *根據下面的信息，是否有真正明顯的情況會導致糟糕的表現？

感謝

克里斯

這裏有一些事實/我們的SVN安裝數字

• 我們的SVN倉庫大約有32000修訂。在磁盤上
• 回購大小：8.3GB
• 我們的開發分支每個都在1400版本的文件夾（19,000版本的文件）
• SVN服務器：1.6.6（r40053）（在美國舉行的Apache Ubunto清醒山貓運行）
• 我在Win7上使用烏龜1.6.9（雖然其他團隊成員使用SmartSVN，他們報告的速度相同）。

編輯

這可能是值得補充的是，當我們的分支/合併，我們從主幹分支始終把整個分支合併回主幹。因此，所有mergeinfo都位於主幹（和分支）文件夾中。

結論

在我而言，它似乎是在合併過程中的瓶頸的磁盤訪問 - 當我提出我的源代碼樹，從我的硬盤我的SSD，同樣合併從50去+/- 5s到7 +/- 1s。
在合併過程中，在進程管理器中觀看烏龜SVN進程非常明顯：在我的硬盤上進行合併時，大部分時間內I/O字節在500kb/s和3Mb/s之間。在SSD上，I/O字節高達10-20Mb/s。 [相當容易混淆的是，我的硬盤驅動器上的某些合併速度與我SSD上的合併速度相當（並且I/O字節的速度相當高） - 在這種情況下，我假設正在讀取的文件中的很多文件已經存在於Windows文件緩存中]。

我發現下面都增加合併速度

• 從&合併到更深的下跌源層級的文件夾：這是不是真的爲我們在「現實生活」的選項，因爲合併跟蹤變得幾乎如果沒有記錄在「trunk-level」文件夾中，則不可能，但確實表明合併更小的樹使得該過程更快。
• 減小被合併工作集的大小有助於提高速度（假設你使用「工作集」深度合併選項而不是完全遞歸） - 所以通過簡單地刪除文件夾（從我在trunk下的工作集） 。

Answer 1

您還可以嘗試在較短的樹中進行合併，以查找它是否更快地返回以查看較小的樹是否有所作爲。

注：已經有很多合併的最新版本改進檢查以下鏈接

http://svn.apache.org/repos/asf/subversion/tags/1.6.11/CHANGES

升級到最新可以幫助有關。

Answer 2

我在合併時注意到的一件事是使用頂級目錄的合併非常快。因此，將功能分支合併回主幹或合併從主幹到功能分支的修訂版本範圍很快。但是合併工作副本中特定文件的更改非常緩慢。出於這個原因，我總是分支整個行李箱，然後改變我需要的任何文件，然後合併整個事物。所以如果你的分支是從一個主幹的子目錄創建的，這可能就是爲什麼它很慢。

Answer 3

另一個因素是兩個分支之間的相對增量。因此，例如，如果您在一個月後從樹幹分支並將樹幹併入分支，則相對而言，這需要很長時間。另一方面，如果你每天從樹幹融入分支，這將會相對較快。