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

发布于 2024-07-13 16:09:03 字数 1430 浏览 4 评论 0原文

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

乍一看，svnsync 似乎非常适合这项工作，但它有一个不幸的问题，即要求它是唯一修改目标存储库的东西。显然，这行不通，因为我们的开发存储库被大量使用。

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

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

我目前倾向于选项 2，因为它似乎让我尽可能接近我需要的东西，但是这仍然是一个很糟糕的选择。这本质上也是我们目前正在做的事情，由人类代替 cron 作业。我对这么长的帖子表示歉意。非常感谢您提供的任何帮助。

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

原文

I have a situation I'm trying to cope with involving my company's SVN server. We keep all of our important code in a locked-down server (we'll call this the "dev" server). There are some files that need to be edited by users outside the corporate network, so we have another SVN server (the "global" server) which is accessible outside the firewall and contains copies of those directories containing the files needed externally. If it matters, the folder structure of the global server is a subset of the dev server (i.e. it's just a few select files/directories, but all have the same relative paths, etc). I've included a brief explanation of why we're trying to do this at the end of the post if you want to read it, but trust me, it has to be done on two separate servers.

At first glance, svnsync seems ideal for this job, but it has the unfortunate problem of requiring that it be the only thing modifying the destination repository. Obviously, that will not work since our dev repository is heavily used.

It seems to me that there are two solutions, and neither of them is a good solution. I'm hoping someone can help me tweak one of these, or better yet provide an alternative.

My first idea is to use externals in the dev server, but this has some problems. Most notably, an external will follow the head revision (we don't want to set it to a specific revision as that would defeat the point), and therefore if we pull up older versions of the dev repo, the externals definitions will still point to the head of the global repo, instead of to what the global repo looked like at the age of our old revision -- thus we will not be able to recreate old releases simply by checking out an old revision.
The other solution is to have a cron job periodically export the latest revision(s) from the global repo and overlay those changed files onto a working copy from the dev repo, then commit the changes. Probably this overlay-and-commit step would be done using the svn_load_dirs.pl script that comes with SVN. This would ideally be done as a post-commit hook on the global repo, but again for firewall reasons, the global server cannot access the dev server, so it must be performed by a machine inside the firewall (probably the dev server machine itself). This approach has the drawbacks of: the dev server can be out of date by as long as the interval on the cron job, and if someone accidentally commits a change to the dev server, their change will get stomped on. (as an aside, if someone can come up with a method of bi-directional syncing, that would be awesome!)

I'm currently leaning towards option 2 because it is seems to get me as close to what I need as possible, but it's still quite a bad option. It's also essentially what we're doing currently, with a human instead of a cron job. My apologies for the long post. Thank you very much for any help you can provide.

Explanation of why: We need these shared files to exist in the dev server directory hierarchy because they are a required part of our software, so builds, testing, etc must have them. I cannot expose the dev server through the firewall -- I have tried to convince the powers that be and failed. I have made it very clear to the decision makers that having two separate servers for this is not how SVN is intended to be used and that there will likely be problems. To help mitigate some of the problems we have foreseen, only the global server will be writable. The dev server's copy of the files will be conceptually read only (only modified when changes are synced from the global server), but I don't think I can actually enforce that read-only policy with SVN access controls because some of the files in that directory structure are not going to exist in the global repo, and thus need to be editable in dev, so I can't blindly make the thing read only. Setting read-only on a per-file basis seems unmaintainable, as there are hundreds and they are often added and deleted.

分享到QQ

分享到微博