在两个可写SVN存储库之间镜像子文件夹

为什么

乍一看, svnsync

在我看来,有两种解决方案,但都不是好的解决方案。我希望有人能帮我调整其中一个,或者更好的是提供一个替代方案。

1. 我的第一个想法是在开发服务器中使用外部,但这有一些问题。最值得注意的是,外部将遵循头部修订(我们不想将其设置为特定的修订,因为这会破坏这一点),因此,如果我们调出开发仓库的旧版本,外部定义仍将指向全局仓库的头部,而不是指向我们旧修订时的全局仓库的样子——因此,我们无法仅仅通过查看旧修订来重新创建旧版本。
2. 另一种解决方案是让cron作业定期从全局仓库导出最新版本,并将这些更改的文件叠加到开发仓库的工作副本上,然后提交更改。这个覆盖和提交步骤可能会使用 svn_load_dirs.pl SVN附带的脚本。理想情况下,这将作为全局仓库上的提交后挂钩来完成,但出于防火墙的原因,全局服务器无法访问开发服务器,因此必须由防火墙内的机器(可能是开发服务器机器本身)执行。这种方法的缺点是:只要cron作业的间隔时间很长,开发服务器就会过时,如果有人不小心向开发服务器提交了更改,他们的更改就会被踩死。(顺便说一句,如果有谁能想出一种双向同步的方法,那就太棒了!)

我目前倾向于选择2,因为它似乎让我尽可能接近我需要的东西,但这仍然是一个相当糟糕的选择。这基本上也是我们目前正在做的,用人类而不是cron作业。很抱歉发了这么长的帖子。非常感谢您能提供的任何帮助。

解释原因: 我们需要这些共享文件存在于开发服务器目录层次结构中,因为它们是我们软件的必需部分,因此构建、测试等必须拥有它们。我无法通过防火墙暴露开发服务器——我试图说服当权者,但失败了。我已经向决策者明确表示,使用两台单独的服务器并不是SVN的目的,而且可能会出现问题。为了帮助缓解我们预见到的一些问题,只有全局服务器是可写的。开发服务器的文件副本在概念上是只读的(仅在从全局服务器同步更改时进行修改),但我认为我实际上无法通过SVN访问控制来强制执行只读策略,因为该目录结构中的一些文件不会存在于全局仓库中,因此需要在开发中进行编辑,所以我不能盲目地将其设置为只读。在每个文件的基础上设置只读似乎是不可维护的,因为有数百个文件,它们经常被添加和删除。