從功能分支到主幹的合併需要45分鐘才能完成。 合併包含了大量的jar（〜250MB），但是，當我使用file：//協議在服務器上完成時，過程花費的時間少於30秒。SVN合併期間的高速緩存憑證
SVN由Apache通過https服務。
SVN服務器上的版本是
svn, version 1.6.12 (r955767)
compiled Sep 3 2013, 17:49:49
我的本地版本
svn, version 1.7.7 (r1393599)
compiled Oct 8 2012, 20:42:17
在檢查Apache日誌我取得了10K的要求，顯然這些請求通過認證就層。
有沒有辦法配置服務器，以便它在一段時間內緩存憑證並且不會發出如此多的驗證請求？
我想棘手的部分是確保憑據只是單一svn'請求'的生活緩存。如果svn合併產生大量獨特的單個https請求，那麼如何確定存儲憑證的時間長度而不增加潛在的安全漏洞？
首先，我強烈建議您將服務器升級到1.7或1.8版本，因爲1.7和newer servers support an updated version of the protocol that requires fewer requests for many actions。其次，如果您使用基於路徑的授權，則可能需要在您的配置中使用SVNPathAuthz short_circuit。如果對於許多遞歸請求（特別是日誌）可能發生的次路徑（即不在請求URI中的路徑）沒有這種情況，那麼在運行這些路徑的授權時，它將通過整個Apache httpd身份驗證基礎結構運行。通過設置而不是運行httpd的整個認證/授權基礎設施，我們只需要mod_authz_svn授權針對路徑的操作。如果您使用LDAP並且需要返回到LDAP服務器來檢查證書，則貫穿整個httpd基礎架構可能會特別痛苦。不使用short_circuit設置的唯一原因是，如果您有一些其他身份驗證模塊取決於路徑，我還沒有看到像這樣的實際設置。
最後，如果您使用LDAP，那麼我建議您配置憑證的緩存，因爲這可以大大加快身份驗證。 Apache httpd提供了mod_ldap module for this and suggest you read the documentation for it。
如果您提供服務器端設置的更多詳細信息，我可能會提供更多的定製建議。
建議您不要將jar放入存儲庫的註釋很有價值，但通過一些配置改進，您可以幫助解決某些緩慢問題。
合併包括一大堆的罐子（250MB〜）
那是你的問題！如果你通過http://通過你的網絡，你必須通過http://發送這些罐子，這可能會非常緩慢。您可以增加Apache httpd的緩存大小，或者您可以設置一個並行svn://服務器，但您仍然通過網絡發送1/4千兆字節的jar。這就是爲什麼file://速度更快。
你不應該在你的Subversion版本庫中存儲jar。這裏的原因：
版本控制爲您提供了大量的電能：
存儲像jar這樣的二進制文件並不能爲您提供。您無法合併二進制文件，並且無法跟蹤其更改。
不僅如此，而且版本控制系統通常使用差異來跟蹤更改。這節省了很多空間。設想一個1千字節的文本文件。在5次修訂中，更改了六行。而不是佔用6K的空間，只有1K加上這六個變化存儲。
當你存儲一個jar文件，然後是該jar文件的新版本時，你不能輕易做一個diff文件，而且由於jar格式是zip文件，所以你不能真正壓縮它們，存儲一個jar版本的五個版本在Subversion中，你存儲的內容非常接近該jar的五倍。如果一個jar文件是10K，那麼你將爲該jar存儲50K的空間。
因此，不僅jar文件佔用大量空間，而且它們不會爲您提供任何存儲功能，它們可以快速接管您的存儲庫。我見過一個網站，其中超過90％的8 GB存儲庫不過是編譯代碼和第三方jar。而且，這些二進制文件的使用壽命也非常有限。所以，在這些地方，他們Subversion版本庫的80％是浪費空間。
更糟糕的是，你傾向於失去你拿到那個罐子的地方，以及它裏面的東西。當用戶放入一個名爲commons-beans.jar的jar時，我不知道該jar的版本是什麼，該jar是否是由某人創建的，以及該jar是否被某人淹沒。我已經看到用戶將兩個單獨的瓶子合併到一個罐子中，以便使用。如果有人調用jar commmons-beanutils-1.5.jar，因爲它是1.5版本，很可能有人會將它更新到版本1.7，但不會更改名稱。 （這會影響構建，你必須添加和刪除，總是有一些原因）。
因此，大量浪費的空間幾乎沒有任何好處，幾乎沒有任何信息。儲存罐子簡直是個壞消息。
但你的構建需要罐子！你該怎麼辦？
獲取類似Nexus或Artifactory的jar庫。這兩個存儲庫管理員都是免費且開源的。
一旦你將jar包存放在那裏，你可以通過Maven，Gradel或者如果你使用Ant並想讓你的Ant構建系統，Ivy來獲取你想要的jar版本。你也可以，如果你不喜歡那樣的想法，可以通過Ant <get/>任務獲取罐子。如果您使用Jenkins，Jenkins可以輕鬆地爲您的Maven存儲庫中的其他項目部署已構建的jar。
所以，擺脫罐子。合併將是文本文件之間的簡單差異。合併分支機構將更加快速，並且通過網絡發送的信息要少得多。如果您不想切換到Maven，請使用Ivy，或者只需使用<wget>任務更新您的版本即可獲取所需的罐子和版本。
這不是一個有用的答案。這聽起來像傳福音。由於項目的性質，很難把所有東西都放在關係上。問題是我如何緩存憑據，你沒有回答。 – opticyclic
這不是福音派。我不推薦任何特定的解決方案。我不是說用git來替換svn。你抱怨你的合併需要45分鐘才能完成，並且它涉及通過網絡發送的1/4千兆字節的罐子。你消除了需要_merge jars_，你的合併將花費不到一分鐘。這樣可以爲你節省更多的時間，比你使用Apache httpd設置所做的更多。 –
你也不需要將所有東西都放到nexus_中。你只需要放置其他項目使用的罐子。如果你有像詹金斯這樣的CI系統，你可以讓詹金斯爲你做這件事（詹金斯有Nexus和Artifactory插件）。第三方jar不必下載，因爲這些存儲庫管理器將從Maven主站回購庫中找到它們，並自動下載它們。 –
我懷疑大部分開銷是在身份驗證請求中，這聽起來更可能是問題是二進制文件的下載和上傳（我不喜歡他們在我的svn repo中，我通常只是構建腳本）。但是你可以測試一下：設置一個沒有身份驗證的臨時服務器，svndump repo直到你做了合併的修改之前，然後進行測試運行。 – Wrikken
你的問題是罐子...不檢查他們。看看artifactory或nexus。 – thekbb
將整個目錄從服務器複製到PC只需要3分鐘，所以我不認爲這些罐子引發了問題。該副本將使用不同的協議（sftp vs https），但其他請求的數量似乎更大。 – opticyclic