我在一个使用位于中心位置的 subversion 服务器的环境中工作，该服务器需要将其内容提供给 4 个不同的环境（prod、test 等...）在这些环境中，我们根本不需要 subversion 功能，仅仅是为了能够通过 http 和本地文件系统访问 repo 中保存的所有 /tags/ 的内容。
为了实现这一点，我们有两种可能的方法：
1) 所有环境中的 subversion 镜像，使用 svnsync 进行更新，然后通过 svn -> web_dav_svn -> davfs (此处 FS 访问) -> apache (此处 HTTP 访问) 在每个位置提供
2）在中心位置使用 svn 导出 /tags，然后将文件 rsyncing 到其他位置，可能在硬链接先前导出的文件结构之后。
虽然选项 1 在许多方面看起来“更巧妙”（虽然要通过 apache 两次？？？），但它将许多风险转移到实时运行环境中，而不是将其保留在中心位置，该位置本质上是“离线”的，因为它从未在这些环境的运行中使用过。我还担心将一个几乎一次性且被忽视的 fuse 项目（如 davfs）放在项目深处。Rsync 很无聊而且很稳定，而且我们想要的只是按照自己的方式访问文件，我们可以使用非常基本和可靠的工具集来实现这一点。
任何想法我都非常感谢。
答案1
你的直觉是正确的。选项 1 似乎带来了很多复杂性，但收益却相对较少。
选项 2 很容易实现，只需一个post-commit钩子即可更新存储库的工作副本，然后使用 rsync 将存储库推送到必要的目的地。如果您的存储库很大，更新本地工作副本（而不是使用svn export）将更加高效。
答案2
提交后挂钩可以工作，但如果在 rsync 中间有写入活动，则可能导致损坏。此外，本地更新会很有效，但它不能保证每个标签的构建都是原始的，因为可能会引入本地更改。
您可能需要考虑以下商业产品Subversion 多站点它将在每个位置保存存储库的精确副本。这些本地副本会在发生更改时自动更新，并在每个节点提供 LAN 性能。
答案3
1) 所有环境中的 subversion 镜像，使用 svnsync 进行更新，然后通过 svn -> web_dav_svn -> davfs (此处 FS 访问) -> apache (此处 HTTP 访问) 在每个位置提供
您无需运行 apache 即可访问 svn 存储库，尤其是当只有一个用户可以访问它时。file://如果存储库存储在本地驱动器上，则可以通过协议访问它。
答案4
使用 svnsync 可能很复杂，但一旦设置好，您就很少需要处理。我在多个位置使用 svnsync 时遇到的唯一问题是偶尔 svnsync 锁无法释放，这可以快速修复，然后所有内容都会再次快速更新。我每年会遇到一两次这种情况，使用中央服务器的三个同步服务器。
svnsync 的另一个优点是，如果您确实需要其他代码，它就在那里。您无需再经历整个设置过程来获取附加内容。
最后，但可能是多个 svnsync 位置的最佳理由是，如果您的中央存储库以不可恢复的方式急剧下降，则可以随时进行故障转移。