subversion server vs. 通过tortoise访问网络仓库

Posted 2023-02-25

【中文标题】subversion server vs. 通过tortoise访问网络仓库

【英文标题】：subversion server vs. network repository access through tortoise

【发布时间】：2010-10-04 12:04:05

【问题描述】：

我的团队目前有 5 名开发人员，我们都通过网络上的计算机 X 上的共享驱动器访问存储库。由于我们都可以访问计算机 X，并且我们可以管理谁可以访问计算机 X，谁不能访问计算机 X，因此我们可以管理谁可以访问我们的存储库。

我的问题是：如果我设置了一个颠覆服务器，我是否会获得任何我还没有的功能？存储库已经内置了用户/密码控制。

我是否能够跟踪当前已签出文件的人员？ 我是否能够为多个人提供锁（仅限 用户 a 和 b 有一个文件被锁定，没有其他用户可以检查 文件）？ 我可以获得任何安全保障吗？

似乎我没有，因为我已经有了没有服务器的用户/组/密码控制。

请告诉我。我正在决定创建服务器是否有任何优势。

谢谢， jbu

【问题讨论】：

编辑：我们网络上这个共享驱动器上的当前存储库已经是一个颠覆存储库。

【参考方案1】：

是的，您会收获很多：您降低了丢失所有数据的风险！

请参阅有关 accessing a repository on a network share 的文档（和警告）。

【讨论】：

很遗憾，对于这个警告，我只有一个赞成票。

【参考方案2】：

当您通过 file:/// URL 访问存储库时，subversion 库将假定存储库在本地磁盘上可用，并且不会尝试（甚至无法）最小化网络 I/O。因此，对于某些需要读取大量数据以确定需要发送到客户端的部分的操作，通过 svn:/// URL 访问存储库快得多 svn switch 命令的情况。

我不敢对 http:// 访问说同样的话。 http 协议在 svn 1.5 中比较繁琐且效率低下。有plans 为 svn 1.7 改进这一点

【参考方案3】：

是的，您可以做几件额外的事情：

其他身份验证机制（基于 HTTP/S 的基本身份验证、ssh 共享密钥身份验证） 使用 Apache+mod_dav_svn，您可以逐个路径地配置更精细的访问控制

edit：不确定您当前是通过文件共享使用 subversion，还是仅使用普通文件共享。 （SVN 也可以使用 file:/// URI）。

【讨论】：

是的，我们目前正在使用 subversion 存储库。很抱歉没有提到这一点。

【参考方案4】：

通常，您不会在 SVN 中“签出”文件。也就是说，您在处理它们时不会锁定它们。

但是，您获得了几件事，（这些只是我的想法）：

提交历史记录（每个文件和整个存储库） 分支/合并选项 能够标记版本（通常是正式版本） 能够将更改回滚到某个修订版（例如，如果最近引入了严重错误） 还有更多

但是请注意，这些好处中的大部分或全部并不是 subversion 所独有的，而是可以从大多数现代版本控制系统中获得。

【讨论】：

实际上我们在没有颠覆服务器的情况下获得了所有这些功能。我们已经有 subversion 存储库 - 只是没有服务器。

啊抱歉，我误会了。我读了它，因为你只是在读/写共享驱动器的文件。

忘了补充：也许你应该编辑你原来的问题，让它更清楚一点（我看到另一个 SO 用户也不确定）。