我遇到了涉及我公司的 SVN 服务器的情况。我们将所有重要的代码保存在一个锁定的服务器中（我们称之为“开发”服务器）。有一些文件需要由公司网络之外的用户编辑，所以我们有另一个 SVN 服务器（“全局”服务器），它可以在防火墙外访问，并包含那些包含外部所需文件的目录的副本。如果重要的话，全局服务器的文件夹结构是开发服务器的一个子集（即它只是几个选择的文件/目录，但都具有相同的相对路径等）。如果您想阅读它，我已经在帖子末尾简要解释了为什么我们要尝试这样做，但相信我，它必须在两个单独的服务器上完成。
乍一看，svnsync这似乎是这项工作的理想选择，但不幸的是，它要求它是唯一修改目标存储库的东西。显然，这不会起作用，因为我们的开发存储库被大量使用。
在我看来，有两种解决方案，它们都不是一个好的解决方案。我希望有人可以帮助我调整其中一个，或者更好地提供替代方案。
- 我的第一个想法是在开发服务器中使用外部，但这有一些问题。最值得注意的是，外部将遵循头部修订（我们不想将其设置为特定修订，因为这会破坏这一点），因此如果我们提取旧版本的开发存储库，外部定义仍将指向到全局 repo 的负责人，而不是全局 repo 在我们旧版本时代的样子——因此我们将无法简单地通过检查旧版本来重新创建旧版本。
- 另一种解决方案是让 cron 作业定期从全局存储库中导出最新修订版，并将这些更改的文件覆盖到来自开发存储库的工作副本上，然后提交更改。可能这个覆盖和提交步骤将使用
svn_load_dirs.plSVN 自带的脚本。理想情况下，这将作为全局 repo 上的 post-commit 挂钩完成，但同样出于防火墙原因，全局服务器无法访问开发服务器，因此必须由防火墙内的机器执行（可能是开发服务器机器本身） . 这种方法的缺点是：开发服务器可能会在 cron 作业的时间间隔内过期，并且如果有人不小心对开发服务器进行了更改，他们的更改将被踩踏。（顺便说一句，如果有人能想出一种双向同步的方法，那就太棒了！）
我目前倾向于选项 2，因为它似乎让我尽可能接近我需要的东西，但这仍然是一个非常糟糕的选择。这本质上也是我们目前正在做的事情，用人类而不是 cron 工作。我为这篇长文道歉。非常感谢您提供的任何帮助。
解释为什么：我们需要这些共享文件存在于开发服务器目录层次结构中，因为它们是我们软件的必需部分，因此构建、测试等必须具有它们。我不能通过防火墙暴露开发服务器——我试图说服那些失败的权力。我已经向决策者明确表示，为此使用两台单独的服务器并不是 SVN 的预期用途，而且可能会出现问题。为了帮助缓解我们已经预见到的一些问题，只有全局服务器是可写的。开发服务器的文件副本在概念上将是只读的（仅在从全局服务器同步更改时修改），但我没有 t 认为我实际上可以使用 SVN 访问控制强制执行该只读策略，因为该目录结构中的某些文件不会存在于全局 repo 中，因此需要在 dev 中可编辑，所以我不能盲目地制作只读的东西。在每个文件的基础上设置只读似乎是不可维护的，因为有数百个并且它们经常被添加和删除。