Windows网络共享上的svn存储库

多台计算机同时访问存储在共享文件系统上的svn存储库是否安全

我正在构建一个应用程序，其中每个Windows客户端计算机都有一个本地工作文件集，并且可以定期与团队的其他成员同步。从服务器的角度来看，除了Windows共享装载点之外，我什么都不想依赖。svn file://URL协议支持共享文件系统，还是假定文件系统是本地的

上面提到了Win9x环境中BDB和FSF的问题，但我不清楚通过file://URL同时访问的存储库在较新版本的Windows（或其他操作系统）中是否安全

编辑 我正在构建的应用程序将直接使用svn，因此如果它允许安全的并发共享协作环境，我愿意构建一个相对受限的环境。

在我的脑海中（我无法在线找到任何信息），我认为，如果您使用的是支持file://协议（例如）的SVN客户机，那么它应该可以正常工作

但是，不幸的是，我找不到该文档，我确实记得文件：//protocol和SVN存在某些问题。如果可能的话，我建议设置一个SVN服务器（工作非常好，易于安装），而不是依赖Windows共享

编辑：我在Stackoverflow上找到了。使用文件协议似乎没有问题

---

编辑2:Neil的链接是我不久前读到的，确实不鼓励使用文件协议。但是，如果使用file://协议意味着使用和不使用源代码管理之间的区别，我建议至少使用它。有些源代码控制总比什么都没有好。

乌龟SVN文档实际上强烈反对它-请参阅。

总结如下：

文件：//access用于本地访问， 仅限单用户访问，尤其是 测试和调试

---

我认为你是在为这种方法设置问题。Windows CIFS（Windows文件共享协议）在操作锁定和同时修改方面存在许多已知问题，因此它要么速度慢，要么不安全，要么两者兼而有之

---

更好的解决方案是设置一个真正的SVN服务器，而不是使用file://url。

我们在Windows上的做法是使用Apache来提供文件。 我们对此设置非常满意。

没错，兄弟

我去过那里。我也使用文件系统在两台机器之间共享“svn服务器”。。。我得到的唯一的东西是损坏的文件和大麻烦

安装了一个svn服务器（CollabNetSubversion服务器），现在一切都运行顺利。。。除了我自己搞砸的时候。。。但这是另一个故事

干杯

---

Aldo

另一个问题类似，但被问及：绩效：

SVN手册建议不要对多个用户使用file://协议

:

不要被让所有用户通过file://url直接访问存储库的简单想法所诱惑。即使每个人都可以通过网络共享随时使用存储库，这也不是一个好主意。它删除了用户和存储库之间的任何保护层：用户可能会意外（或故意）损坏存储库数据库，很难使存储库脱机进行检查或升级，还可能导致文件权限问题（请参阅“支持多个存储库访问方法”一节）)。请注意，这也是我们警告不要通过svn+ssh://URL访问存储库的原因之一。从安全角度看，这实际上与本地用户通过file://访问存储库是一样的，如果管理员不小心，可能会导致所有相同的问题

---

从技术角度来看，完全可以对多个用户使用file://协议：

由于subversion在FSF上使用自己的锁定机制，因此标准svn使用时不会发生损坏。否则，SVN手册将明确说明如何避免这种设置，因为它在BDB后端中提到了这个问题

然而，真正的问题是如何限制对存储库数据库的访问，使其不能使用任何其他任意工具访问存储库数据

如果使用file://每个人都可以打开SVN存储库中的每个文件并更改其内容，这肯定会导致存储库损坏

见鬼，每个用户都可以删除整个存储库

---

您不能限制对svn工具的访问，因此不应使用file://protocol.

我同意在共享上使用VisualSVN。我强烈反对您的第二次编辑-不可靠的源代码管理比没有更糟糕。这些是TortoiseSVN文档，而不是svn文档本身。我想知道这是陆龟们的局限性/观点，还是svn本身的问题。另外，我愿意在环境限制方面做出很多让步；如果我能找到一组可以工作的需求，我会很高兴地约束自己（假设其中一个需求不是“运行服务器进程”）。我怀疑乌龟开发人员比你或我更了解子版本。乌龟是建立在颠覆代码上的，所以我猜这是一个基本的颠覆限制。我认为你犯了一个很大的错误。多个用户在Windows共享上使用单用户软件总是充满问题。但这是你的葬礼。根据我个人的经验，我不会这么做的！只需安装一个服务器。这并不难，而且会帮你省去很多麻烦。我认为“设置服务器”这个短语会让人尖叫着跑开。我们在这里真正谈论的是在一些服务器上运行svnserve或apache模块