5

如果多个用户访问基于文件的 SVN 存储库同时提交许多事情，SVN 能否保证数据完整性？如果是，怎么做？或者，如果不是我应该在多用户情况下使用哪种服务方法？

4

3 回答 3

5

从颠覆书：

运行在存储库所在的同一台机器上的客户端可以使用带有 file:// 方案的 URL 同时访问 Subversion 存储库。但是典型的 Subversion 设置涉及到一台服务器机器，可以从办公室各处的计算机上的客户端访问——或者，也许是全世界。

该方案存在几个问题file://：

  • 它必须在同一台服务器上。有些人将存储库放在 Windows 共享或 NFS 驱动器上，然后让人们安装共享并使用该file://方案。这行不通。它必须在同一台机器上才能使file://访问方案正常工作。
  • 这是不安全的。这是最大的问题。所有用户都必须对存储库中的文件具有读/写权限，这意味着有人可以删除存储库或使用 Subversion 背后的文件进行处理。
  • 使用svn://andhttp://设置起来并不难。我使用 Subversion 作为我自己的个人版本控制系统，并使用该svn://方案。Subversion withhttp://稍微复杂一些，但我可以在大约一个小时内可靠地完成。
于 2011-11-11T02:54:32.403 回答
3

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

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

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

于 2011-11-11T03:19:14.750 回答
2

Subversion 提交被设计为原子的。因此，多个用户同时提交相同的修订号应该是不可能的。从颠覆书：

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

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

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

于 2011-11-11T02:45:58.357 回答