可以基於文件的SVN存儲庫支持同時多用戶情況嗎？

Question

如果多個用戶訪問基於SVN的文件庫同時提交很多事情，SVN可以保證數據的完整性嗎？如果是，如何？或者，如果它不是我應該用於多用戶情況的服務方法？

Answer 1

Subversion提交被設計爲原子。因此，多個用戶在同一時間提交相同的版本號是不可能的。來自subversion book：

svn commit操作將任意數量的文件和目錄的更改發佈爲單個原子事務。在您的工作副本中，您可以更改文件的內容;創建，刪除，重命名和複製文件和目錄;然後提交一組完整的更改作爲原子事務。

通過原子事務，我們的意思是簡單的：或者所有的變化發生在倉庫中，或者它們都不會發生。 Subversion試圖在面對程序崩潰，系統崩潰，網絡問題和其他用戶的操作時保持這種原子性。

每次存儲庫接受提交時，都會創建一個稱爲修訂的文件系統樹的新狀態。每個修訂版都分配有一個唯一的自然數，比先前版本的數字大一個。新創建的版本庫的初始版本編號爲0，並且只包含一個空的根目錄。

Answer 2

從Subversion書：//方案：

Subversion版本庫可以同時在其上存儲庫所在使用攜帶文件的URL在同一臺機器上運行的客戶端訪問。但是典型的Subversion設置涉及到一臺單獨的服務器機器，可以通過辦公室內的計算機上的客戶端訪問 - 或者可能遍佈全球。

有幾個問題與file://方案：

• 它必須是在同一臺服務器上。有人將存儲庫放在Windows共享或NFS驅動器上，然後讓人們安裝共享並使用file://方案。這不起作用。它必須位於同一臺機器上才能使file://訪問方案正常工作。
• 這是不安全的。這是最大的問題。所有用戶必須對存儲庫中的文件具有讀/寫權限，這意味着有人可以刪除存儲庫或使用Subversion背後的文件。
• 使用svn://和http://並不是很難設置。我使用Subversion作爲我自己的個人版本控制系統，並使用svn://方案。顛覆與http://稍微更多的參與，但我可以在大約一個小時內可靠地做到這一點。

Answer 3

只是爲了分享我過去的經驗。

我的公司在SVN上託管了一個項目。最初開發團隊使用file：//協議訪問SMB共享捲上的存儲庫。老實說，它似乎工作正常。然而，表現簡直太糟糕了。當我說可怕的時候，就好像花更多的時間來分享更新/提交。此外，我認爲你可以看到來自不同來源或參考的類似聲明：file：//協議僅針對本地機器上的單用戶訪問。

當我參與項目時，我立即改用svnserve來實現多用戶訪問的臨時策略（雖然我個人使用http來管理其他svn倉庫）。我們立即看到了數量級的性能改善。設置的額外時間僅需2分鐘（因爲我們有一臺服務器，我可以簡單地以控制檯模式啓動svnserve並保持運行狀態）。除非你真的不能安排任何機器來運行svnserve/apache，否則我看不到有任何理由堅持使用file：//協議來實現多用戶訪問。