我有一种情况,我正试图处理涉及我公司的SVN服务器。我们将所有重要的代码保存在一个锁定的服务器中(我们称之为“dev”服务器)。有些文件需要由企业网络之外的用户编辑,因此我们有另一个SVN服务器(“全局”服务器),它可以在防火墙之外访问,并且包含包含外部所需文件的目录副本。如果重要的话,全局服务器的文件夹结构是dev服务器的一个子集(即,它只是一些选择的文件/目录,但所有文件/目录都具有相同的相对路径等)。我已经包括了一个简短的解释
为什么?
如果你想读的话,我们会在文章结尾处尝试这样做,但是相信我,这必须在两个独立的服务器上完成。
乍一看,
svnsync
似乎是这个工作的理想选择,但它有一个不幸的问题,即要求它是修改目标存储库的唯一工具。显然,这是行不通的,因为我们的开发库被大量使用。
在我看来,有两种解决方案,它们都不是一个好的解决方案。我希望有人能帮助我调整其中的一个,或者更好地提供一个替代方案。
-
我的第一个想法是在dev服务器中使用externals,但这有一些问题。最值得注意的是,外部机构将遵循头部修订(我们不希望将其设置为特定修订,因为这样会破坏要点),因此,如果我们调出较旧版本的dev repo,外部机构的定义仍将指向全球repo的头部,而不是指全球repo在旧修订时代的样子。--因此,我们无法通过签出旧版本来重新创建旧版本。
-
另一种解决方案是让cron作业定期从全局repo导出最新版本,并将这些更改的文件覆盖到dev repo的工作副本上,然后提交更改。可能这个覆盖和提交步骤将使用
svn_load_dirs.pl
SVN附带的脚本。理想情况下,这将作为全局repo上的提交后挂钩完成,但由于防火墙原因,全局服务器无法访问dev服务器,因此必须由防火墙内的计算机(可能是dev服务器本身)执行。这种方法的缺点是:只要cron作业上的间隔时间长,dev服务器就可能过时,如果有人意外地向dev服务器提交了更改,那么他们的更改将受到限制。(顺便说一句,如果有人能想出双向同步的方法,那就太棒了!)
我目前倾向于选择2,因为它似乎能让我尽可能接近我需要的东西,但这仍然是一个相当糟糕的选择。这也是我们目前正在做的工作,用人代替人脉。我为这封长信道歉。非常感谢您提供的帮助。
解释原因:
我们需要这些共享文件存在于dev-server目录层次结构中,因为它们是我们软件的必需部分,所以构建、测试等必须具有它们。我不能通过防火墙公开dev服务器——我试图说服那些已经失败的力量。我已经向决策者清楚地表明,拥有两个独立的服务器并不是SVN的用途,而且很可能会出现问题。为了帮助缓解我们已经预见到的一些问题,只有全局服务器是可写的。dev服务器的文件副本在概念上是只读的(仅当更改从全局服务器同步时才修改),但我认为我实际上不能用svn访问控制来实施只读策略,因为该目录结构中的某些文件在全局repo中不存在,因此需要在de中编辑。所以我不能盲目地把它变成只读的。以每个文件为基础设置只读似乎是不可维护的,因为有数百个文件,它们经常被添加和删除。
