logo标签列表

在Windows网络共享上的SVN代码库

svnfilesystemsberkeley-dbnetwork-sharefsfs
9

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

我正在构建一个应用程序，在该程序中，每台Windows客户端机器都有一个本地工作集文件，并且可以定期与团队的其余部分同步。从服务器的角度来看，我想依靠的仅仅是一个Windows共享挂载点。svn file:// URL协议是否支持共享文件系统，或者它是否假定文件系统是本地的？

Subversion文档提到了在Win9x环境下使用BDB和FSFS时存在问题，但我不确定通过file:// URL并发访问的仓库在较新版本的Windows（或其他操作系统）中是否安全。

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

你实际上正在尝试解决什么问题/你必须克服什么限制？ - Jim T
好问题。我正在构建一个带有协作功能的Windows桌面应用程序。该应用程序需要在仅有的保证共享通信介质是Windows（CIFS）挂载的环境中运行。目前，我已经有了一个可行的解决方案，但出于许多原因，我宁愿使用像SVN这样的抽象层而不是自己处理所有锁定和文件处理问题。基本上，我的持久性模型是一个事务日志记录列表，在应用程序启动时进行重放。因此，“所有”我需要的就是一种协作维护有序列表及其不可避免的冲突的方法。 - Patrick Linskey
7个回答
11

Tortoise SVN文档实际上强烈反对这样做-请参见this link。

总结一下：

file://访问仅用于本地单用户访问，特别是测试和调试。

1
这些是TortoiseSVN文档，而不是svn文档本身。我想知道这是TortoiseSVN团队的限制/意见，还是svn本身的问题。另外，我愿意在环境限制方面做出很多让步；如果我能找到一个狭窄的要求集合可以使用，我将很高兴地遵守它们（假设其中一个要求不是“运行服务器进程”）。 - Patrick Linskey
2
我有点怀疑乌龟开发人员对Subversion的了解比你和我更多。乌龟是基于Subversion代码构建的，所以我猜这是一个基本的Subversion限制。 - anon
3
我认为你正在犯一个大错误。在Windows共享上使用单用户软件一直存在着很多问题。但这是你自己的事情。 - anon
2
从个人经验来看，我不会这样做！只需设置一个服务器。这并不难，而且可以避免许多麻烦。 - Judge Maygarden
4
我认为短语“设置服务器”会让人们尖叫着逃开。实际上，我们只是在谈论在某个系统上运行svnserve或apache模块。如果您愿意，可以将其放在自己的桌面上（不建议这样做；最好将其放在您考虑用于file://的文件服务器上）。SVN需要很少的系统资源，不需要专用的系统。 - rmeador
显示剩余8条评论
10

还有一个类似的问题，但是关注的是性能：Subversion协议性能

《SVN Book》建议您不要使用file://协议供多个用户使用

选择服务器配置：

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

有趣...谢谢分享链接！我想知道他们关注的仓库损坏问题是什么。 - Patrick Linskey
2
据我所知，SVN使用文件进行锁定，而不是实际的文件系统级锁定（因为它们在文件系统和操作系统之间的支持并不统一）。在网络共享上可能存在竞争条件，因为假设是原子的文件系统操作（例如移动）在通过网络访问时无法保证是原子的。这是由SVN开发人员在某个时间点向我详细解释过的，但我可能忘记了一些细节，但我认为这就是要点。 - rmeador
5
从技术角度来看，使用file://协议与多个用户一起使用是完全可行的：
在标准svn使用中不会发生损坏，因为subversion在FSFS上使用自己的锁定机制。否则，SVN书中会明确说明要避免此类设置，因为它在BDB后端中提到了这个问题。
然而，真正的问题是如何限制对存储库数据库的访问，以防止使用任何其他任意工具访问存储库数据？
如果您使用file://，每个人都可以打开SVN存储库中的每个文件并更改其内容，这肯定会导致存储库损坏。
甚至每个用户都可以删除整个存储库！
您无法限制对svn工具的访问，因此不应使用file://协议。
我认为FSFS和file:协议之间有区别，不是吗？ - sbi
1
你有任何支持文件不会损坏的理由吗？还是这基于（可能合法的）假设，即SVN团队会在任何环境下避免文件损坏？ - Patrick Linskey
正如 Meadows 所述：“由于假定为原子操作（即移动）的文件系统操作在通过网络访问时不能保证是原子操作，因此在网络共享上存在竞争条件是可能的。”然而，我对这个问题没有任何见解。 - Peter Parker
2
从我的个人经验来看（我在网上也没有找到相关信息），如果您使用支持file://协议的SVN客户端（例如TortoiseSVN），它应该可以正常工作。
然而，很不幸我无法找到相关文件，我记得file://协议和SVN存在某些问题。如果可能的话，我建议设置一个SVN服务器（VisualSVN非常好用且易于设置），而不是依赖Windows共享。
编辑：我在Stackoverflow上找到了this discussion。看起来使用file协议并没有问题。
编辑2：Neil的链接是我以前读过的，并且不鼓励使用file协议。然而，如果使用file://协议意味着使用和不使用源代码控制之间的差异，我建议至少使用它。一些源代码控制总比没有好。
我同意使用VisualSVN而不是共享。 - Nick
8
我强烈不同意你的第二次编辑 - 不可靠的信息来源控制比没有控制更糟糕。 - anon
2
我认为你采用这种方法会遇到问题。Windows CIFS(即Windows文件共享协议)在操作锁定和同时修改方面存在很多已知问题，所以要么速度慢，要么不安全，或两者兼而有之。
一个更好的解决方案是设置一个真正的SVN服务器，而不是使用file:// URL。
我很满意“狗慢”的速度，事实证明，“猫慢”也可以。只是不能“不安全”。我知道建立服务器是更好的方法，但可惜对于这个产品来说不是一个选项。 - Patrick Linskey
2

没错，兄弟...

我也曾经这样做。我也使用文件系统在几台机器之间共享“svn服务器”... 我所得到的唯一结果就是损坏的文件和大量的头疼...

安装了一个svn服务器（CollabNetSubversion Server），现在一切都很顺利... 除非是我自己搞砸了... 但这又是另外一个故事...

干杯。

Aldo

你遇到了什么类型的损坏问题？ 你是使用BDB还是FSFS？ 你使用的是什么类型的文件系统？ - Patrick Linskey
0

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

或者你可以使用工具来完成这个任务：VisualSVN服务器。 - reinierpost
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接