基于文件的SVN存储库可以同时支持多用户情况吗？

Question

如果多个用户访问基于文件的SVN存储库同时提交多个内容，SVN能否保证数据的完整性？如果是的话，怎么样？或者，如果不是我应该为多用户情况使用什么服务方法？

Answer 1

来自Subversion书：

  

使用带有file：// scheme的URL，运行在存储库所在的同一台机器上的客户端可以同时访问Subversion存储库。但典型的Subversion设置涉及从办公室或整个世界各地的计算机上的客户端访问单个服务器计算机。

file://计划存在以下几个问题：

• 必须在同一台服务器上。有人将存储库放在Windows共享或NFS驱动器上，然后让人们挂载共享并使用file://方案。这不行。它必须位于同一台计算机上才能使file://访问方案正常工作。
• 这是不安全的。这是最大的问题。所有用户必须对存储库中的文件具有读/写权限，这意味着有人可以删除存储库或者使用Subversion后面的文件来保存文件。
• 使用svn://和http://并不是很难设置。我使用Subversion作为我自己的个人版本控制系统，我使用svn://方案。使用http://的Subversion稍微复杂一些，但我可以在大约一个小时内完成。

Answer 2

Subversion提交被设计为原子的。因此，多个用户同时提交相同的修订号是不可能的。来自subversion book：

  

svn commit操作将对任意数量的文件和目录的更改发布为单个原子事务。在您的工作副本中，您可以更改文件的内容;创建，删除，重命名和复制文件和目录;然后将一组完整的更改作为原子事务提交。

     

通过原子事务，我们只是意味着：要么所有的更改都发生在存储库中，要么都不会发生。 Subversion试图在程序崩溃，系统崩溃，网络问题和其他用户的行为面前保留这种原子性。

     

每次存储库接受提交时，都会创建文件系统树的新状态，称为修订。每个修订版都分配了一个唯一的自然数，一个大于先前修订版的编号。新创建的存储库的初始修订版编号为0，只包含空的根目录。

Answer 3

只是为了分享我过去的经历。

我公司在SVN上有一个项目。最初，开发团队使用file：//协议访问SMB共享卷上的存储库。老实说它似乎工作正常。然而，表现简直太糟糕了。当我说糟糕时，就像花费几分钟来进行更新/提交。此外，我认为您可以从不同的来源或参考中看到类似的声明：file：//协议仅针对本地计算机中的单用户访问。

当我参与该项目时，我立即更改为使用svnserve进行多用户访问的临时策略（尽管我个人使用http来管理我管理的其他svn存储库）。我们立即看到了数量级的性能提升。设置的额外时间仅为2分钟（因为我们有一台服务器，我只需在控制台模式下启动svnserve并让它继续运行）。除非你真的无法安排任何机器运行svnserve / apache，否则我看不出任何理由坚持使用file：//协议进行多用户访问。