我正在一个在中心位置使用Subversion服务器的环境中工作，该环境需要将其内容提供给4个不同的环境（prod，test等）。在这些环境中，我们不需要subversionfunction，只是为了能够通过http和本地文件系统访问repo内所有/ tags /的内容。
要做到这一点，我们有两种可能的方法：
1）颠覆所有环境中的镜像，使用svnsync进行更新，然后通过svn – > web_dav_svn – > davfs（FS访问此处） – > apache（这里的HTTP访问）
2）svn导出/标签在一个中央位置，然后将文件rsyncing到其他位置，可能在硬链接之前导出的文件结构。
虽然选项1在许多方面看起来是“光滑的”（虽然两次经过apache），但它将大量的风险降低到一个实时的运行环境，而不是将其保持在中央位置，这基本上是“离线”因为它从来没有被用于这些环境的运行。 我也很关心把一个非常一次性的和被忽视的导火索项目如davfs这么深入到项目中。 Rsync是无聊而稳定的，我们只需要根据自己的条件就可以访问文件，我们可以通过一个真正的基础和可靠的工具集来获得。
任何想法真的很感激。
你的直觉是正确的。 备选scheme1似乎在收益相对较less的情况下引入了很多复杂性。
选项2将很容易实现一个post-commit钩子，更新存储库的工作副本，然后使用rsync将存储库推送到必要的目的地。 如果你的版本库很大，更新一个本地工作拷贝 – 而不是使用svn export – 会更有效率。
提交后挂钩可以工作，但如果在rsync中间有写入活动，则会导致可能的损坏。 而且本地更新也是有效的，但是不能保证每个标签的原始构build，因为可能引入本地更改。
你可能要考虑一个商业产品，比如Subversion MultiSite ，它会在每个位置保留一个精确的版本库副本。 这些本地副本会在更改时自动更新，并在每个节点上提供LAN性能。
1）颠覆所有环境中的镜像，使用svnsync进行更新，然后通过svn – > web_dav_svn – > davfs（FS访问此处） – > apache（这里的HTTP访问）
你不需要运行apache来访问svn仓库，特别是当只有一个用户可以访问它时。 如果存储在本地驱动器上，则可以通过file://协议访问存储库。
使用svnsync可能会很复杂，但一旦安装，你就不得不处理。 关于我在多个地方使用svnsync的唯一问题是偶尔的svnsync锁，它不能被快速修复，然后所有的东西都可以很快被更新。 每年有一次或两次使用中央服务器的三个同步服务器。
svnsync的另一个优点是，如果你确实需要其他的代码，那它就在那里。 您不需要经过另一个设置的过程来获得额外的内容。
而最后一个，也许是多个svnsync位置的最好的原因，如果你的中央存储库采取了难以采取的，不可恢复的方式。