2009-07-25 77 views
7

選擇Apache Subversion我的版本控制需求(和AnkhSVN/TortoiseSVN我主要的Subversion客戶端)之後。現在我試圖選擇SVN服務器來提供對SVN存儲庫的遠程訪問。我已經看過他們夫婦:選擇一個Subversion服務器

我已經安裝在每一個虛擬機嘗試一下,但還沒有找到足夠的區分大多足以挑選具體的。現在我有幾件事需要決定。

  1. 協議
  2. 廠商
  3. SSL


1.我已閱讀,HTTP比SVN協議得多。雖然我的項目通常不是太大(實際上只是最初的導入是耗時的部分),但我確實希望獲得SVN的性能優勢,以及避免我的HTTP日誌充斥着SVN條目(其中I至今尚未能隔離成單獨的LOG文件)

但我喜歡使用Apache模塊或VisualSVN提供的網頁界面。我並不需要向其他人(甚至是我自己的系統)提供我的東西,所以它不是關鍵,但它肯定允許可擴展性。


2.選擇協議後(假設我選擇);我需要幫助決定使用哪個供應商。我最初使用了Tigris發行版中的Apache模塊。我已經刪除了(嗯,只是禁用它),我目前正在使用VisualSVN(這是HTTP,因此很慢)。我看到人們贊同夏普和絲綢,但他們似乎更小,獨立發行。
另一方面,Collabnet似乎比我需要的更精細。基本上,除非我能說服其中一個人,否則我主要是試圖在官方的Tigris和VisualSVN之間做出選擇。


3.我也試過用SSL搞亂沒有太大的成功(我買不起真正的CA,所以我在VisualSVN中使用自簽名證書)。我很樂意使用SVN + SSH/HTTPS,但是如果我在我自己的系統上使用它,那就沒有必要,如果我在外部使用它,那麼我的自簽名證書將無濟於事。


我想我甚至可以使用本地存儲庫;我會認爲這將是最快的。但是,如果我擴展,我更喜歡更正式的解決方案。 (我認爲只使用TortiseSVN客戶做本地服務器的工作。)


因此,在總結,我需要哪些服務器上的一些建議(小號?)來使用。如果我能讓VisualSVN提供一個供Web使用的HTTP接口,而且還可以在客戶端使用SVN協議,最好是在每個客戶端上都使用SSL,那麼最好的辦法是。那可能嗎?工作是否太多(我真的想回到我的項目上而不是所有這些元工作上)。



非常感謝。

編輯

我想我應該給我的情況下,提供一些信息,以澄清事情。

  • (目前)單系統,(較老的P4,Windows中,1GB SDRAM)
  • (目前)單個開發者(我)
  • (目前)相對較小的項目(< 2MB)
  • 無數項目(> 100個人應用程序,遊戲,圖書館,網站等)
  • 需要外部(特別是我自己的庫以及第三方標題,Boost等)
  • ?嗯,還有什麼...
+3

我還是noobish,但我的猜測是,這是將被妥善被問及Serverfault一個問題:http://serverfault.com – 2009-07-25 19:44:32

+0

我有幾個使用HTTP訪問的100Mb項目。性能完全不是問題。我不擔心或打擾svn://直到性能對你來說真正的問題。 – nos 2009-07-25 19:49:26

回答

5

編輯:這裏閱讀其他的答案後,有一兩件事,我想我應該不在話下。如果您嘗試使用一臺服務器,則您要求其提供服務的存儲庫與您要求提供另一種服務器類型的存儲庫沒有區別。

換句話說,如果您決定立即嘗試一臺服務器,則可以稍後切換到其他類型的服務器,而不會丟失存儲庫。當然,工作副本以及您在項目中完成的任何絕對外部引用都必須更改,但您可以使用歷史記錄和所有內容保留存儲庫。


我安裝VisualSVN Server,當它宣佈,並且是與它很高興,一會。

但是,速度問題讓我轉向作爲Subversion命令行包一部分提供的主要svnserve服務器。

主要的問題是,我正在使用.NET,我選擇了添加幾個外部Subversion引用到我的項目。

首先,我的課程庫中的每個項目都由我的密鑰簽名。其次,添加外部第三方庫,如SQLiteNUnit作爲外部參考。

每個項目都有自己的外部參考。我這樣做是爲了能夠創建一個新的應用程序項目,然後爲我需要的我的類庫的某些部分創建新的外部引用,並使這些引用完整。如果我在.NET中的類庫解決方案有一個用於簽名密鑰文件的外部引用,並且該文件不作爲任何單個項目的一部分提供,但位於所有項目之外的磁盤上,但位於我的解決方案的本地磁盤上沒有工作。因此,我的類庫解決方案包含15-20個項目,每個項目至少有一個外部引用到簽名密鑰,我所有的數據項目都有外部引用到SQLite庫,單元測試庫有4-5個外部參考。

最終的結果是,即使我已經擁有所有最新的文件,目錄和所有內容,解決方案級別的單個更新花費了大約2分鐘的時間才能完成。每個外部引用都需要10到20秒才能完成,只是爲了驗證我有需要的修訂。

當我切換到svnserve時,那2分鐘減少到3秒左右。這是當地的交通頭腦,所以當然這在互聯網上會有所不同。問題是,那2分鐘也是本地流量。

所以,雖然我絕對喜歡的界面VisualSVN服務器爲我提供了,包括能夠容易設置訪問權限的用戶,即Apache服務器模塊提供了我的速度是什麼svnserve的比較絕對可怕和本地的Subversion協議。

請注意,從那時起,我已經安裝了一個單獨的Apache服務器,通過大量配置文件進行掃描,並通過Apache設置Subversion而不是通過VisualSVN服務器,只是爲了確保它不僅僅是VisualSVN,而且我證實我觀察到的速度不是VisualSVN團隊的工作。看來HTTP協議或Apache模塊並不那麼快。

我的建議是在可能的情況下使用主svnserve服務器。可能需要一些工作才能瞭解配置文件的授權和類似情況,但單獨的刺激因素(即對速度沒有任何刺激)將超過這個可能性。

+0

我喜歡有關倉庫的信息是標準的,因此便於攜帶。這告訴我,我可以堅持我目前的工作,並根據需要更改。 – Synetech 2009-07-25 21:05:06

+1

在Subversion 1.7中對HTTP協議進行了改進:http://subversion.apache.org/docs/release-notes/1.7.html#httpv2 – 2012-07-19 13:14:28

0

我在家中和工作中使用CollabNet。這很好 - 沒有表現抱怨。

2

重新訪問速度:我看到一個Apache https:需要硬件更新的SVN服務器。我似乎記得它主要是缺乏內存,這減慢了許多爭奪機器資源的Apache進程。但那是20個開發者在一個20GB的簽出樹上進行項目合作(大量的二進制文件,經常改變)。而對裝備適中的服務器的更新解決了這個問題。另外,在那個項目中,我不得不知道,在Linux下的ext3 FS上,SVN比在Windows下的NTFS要快一個數量級。標記:運行在Windows上的虛擬機中的Linux花費十分之一的時間用於與VM運行在Windows上的Windows盒子競爭。 (我們總是試圖用於Windows的OS ext3驅動程序,看看它是否會使SVN在Windows上的運行速度比它的本地FS版本要快,但是,在我們嘗試之前,我已經離開了該項目。)

無論如何,不像你決定投入永恆的石頭。您可以嘗試一件事,在真實項目中對其進行徹底測試,並在稍後切換到其他服務器和協議。 (甚至有一個SVN命令來切換檢出樹的URL 。這可以用來切換協議,而無需重新檢查所有內容。)

下面是我會考慮的關於協議的決定:If您有一個可用於登錄SVN的AD或LDAP基礎架構,請嘗試使用http/https:協議選項之一。如果你沒有這個,並且你不需要它,你可以通過SVN自己的方式登錄,爲什麼不使用svn:協議提供的速度?

我從來沒有見過人們使用WebDAV訪問的SVN回購協議。 IME他們總是希望在訪問每個網頁時具有歷史記錄(WebDAV不提供此功能,AFAIK),因此他們使用SVN的網頁前端之一。我從來沒有檢查過,但我只是假設像ViewVC之類的東西不關心他們用於訪問回購協議的協議。

至於你想使用哪種發行版本 - 我認爲這主要歸結於個人喜好,因爲下面的代碼是相同的。我更喜歡我沒有註冊的下載和明確針對我想要安裝它們的平臺的發行版。但那可能只是我。

但是,如果您的存儲庫可以從Internet訪問,您可能需要考慮一個難題:當SVN項目製作了新的點發布版時,過去多久它採用不同的發行版以趕上。由於這些可能是安全修復程序,因此您可能更喜歡那些通常可以更快地提供修復程序的修補程序。

1

我們使用由XEN虛擬機內的CentOS 5.3運行的Apache提供的HTTP提供我們的SVN存儲庫。

我會觀察到,在大文件上進行提交或簽出,以接近網絡速度傳輸該文件。在檢出或提交大量小文件時,HTTP請求的開銷更加明顯。

與編譯代碼中的時間尺度相比,SubVersion不被視爲公司內部的瓶頸。

(這是我與一隊的10個開發經驗)