在两个可写的 SVN 存储库之间镜像一个子文件夹 [英] mirroring a subfolder between two writable SVN repos

问题描述

我正试图应对涉及我公司的 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.

乍一看，svnsync 似乎是这项工作的理想选择，但不幸的是，它要求它是唯一修改目标存储库的东西.显然，这不会起作用，因为我们的开发存储库被大量使用.

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.

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

1. 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.
2. 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!)

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

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.

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

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.

推荐答案

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

You could try to set up a write-through proxy, so that all writes on your public repository are automatically forwarded to the private server.

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

I've never done this, but here's some documentation on the subject.

这篇关于在两个可写的 SVN 存储库之间镜像一个子文件夹的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！