镜像两个可写SVN repos之间的子文件夹

Question

我有一种情况，我正在努力应对涉及我公司的SVN服务器。我们将所有重要代码保存在一个锁定的服务器中（我们将其称为“dev”服务器）。有些文件需要由公司网络外的用户进行编辑，因此我们有另一个SVN服务器（“全局”服务器），可以在防火墙外部访问，并包含那些包含外部所需文件的目录的副本。如果重要，全局服务器的文件夹结构是开发服务器的子集（即它只是几个选择文件/目录，但都具有相同的相对路径等）。我已经包含了一个简短的解释为什么我们试图在帖子的最后做这个，如果你想阅读它，但相信我，它必须在两个单独的服务器上完成。

乍一看，svnsync似乎非常适合这项工作，但它有一个不幸的问题，即要求它是修改目标存储库的唯一方法。显然，由于我们的dev存储库被大量使用，这将无效。

在我看来，有两种解决方案，它们都不是一个好的解决方案。我希望有人可以帮助我调整其中一个，或者更好，但提供另一种选择。

1. 我的第一个想法是在开发服务器中使用外部，但这有一些问题。最值得注意的是，外部将遵循头部修订（我们不希望将其设置为特定修订，因为这会破坏该点），因此如果我们提取旧版本的dev repo，外部定义仍将指向对于全球回购的负责人，而不是我们旧版本时代的全球回购的样子 - 因此我们将无法仅通过查看旧版本来重新创建旧版本。
2. 另一个解决方案是让cron作业定期从全局存储库中导出最新版本，并将这些已更改的文件覆盖到dev repo的工作副本上，然后提交更改。这个覆盖和提交步骤可能会使用SVN附带的svn_load_dirs.pl脚本完成。理想情况下，这将作为全局存储库上的提交后挂钩完成，但出于防火墙原因，全局服务器无法访问开发服务器，因此必须由防火墙内的计算机执行（可能是开发服务器计算机本身） 。这种方法的缺点是：只要在cron作业上有间隔，dev服务器就会过时，如果有人意外地将更改提交到dev服务器，他们的更改就会被踩到。 （顺便说一句，如果有人能想出一种双向同步的方法，那就太棒了！）

我目前倾向于选项2，因为它似乎让我尽可能接近我所需要的，但它仍然是一个非常糟糕的选择。它本质上也是我们目前正在做的事情，用人而不是cron工作。我为长篇大论道歉。非常感谢您提供的任何帮助。

解释原因：我们需要这些共享文件存在于dev服务器目录层次结构中，因为它们是我们软件的必需部分，因此构建，测试等必须具有它们。我不能通过防火墙暴露开发服务器 - 我试图说服那些失败的权力。我已经向决策者明确表示，为此设置两个独立的服务器并不意味着如何使用SVN并且可能存在问题。为了帮助缓解我们预见到的一些问题，只有全局服务器才可写。开发服务器的文件副本将在概念上只读（仅在从全局服务器同步更改时才进行修改），但我认为我不能实际执行具有SVN访问控制的只读策略，因为某些文件位于该目录结构不会存在于全局repo中，因此需要在dev中进行编辑，因此我不能盲目地将该事物只读。在每个文件的基础上设置只读似乎是不可维护的，因为有数百个并且经常添加和删除它们。

Answer 1

您可以尝试设置直写代理，以便公共存储库上的所有写入都自动转发到私有服务器。

我从来没有这样做，但是here有关于这个主题的一些文档。

Answer 2

在源控件上没有变得复杂，可能值得分割两个repos（从dev中删除全局代码），然后让dev的构建消耗全局构建。由于你的内部人员将能够同时承诺这两者，并且在两者中都有相同的代码是永远难以理解的。

你没有提到所涉及的语言工具......所以很难知道它是如何适合的。考虑构建全局发布工件，然后构建全局解析该依赖项。

你在备选方案2中没有提到的一件事是，你将失去审计跟踪，因为提交到全局的用户将不是覆盖并提交给dev的用户。