通过FTP同步SVN

Question

我的团队正在与另一家公司的团队合作，这些团队的IT政策非常严格。我们不允许任何直接访问其SVN服务器。他们不允许访问我们的SVN服务器。我们唯一的选择是访问共享的FTP服务器。所以，我正在寻找保持我们的存储库同步的建议。请注意，此FTP服务器是除电子邮件之外的唯一通信机制，因此svn：externals不是一个选项。

我目前的想法是两个方向上的夜间（或经常需要的）差异/补丁。对于它的价值，我们每个人都使用相当独立的组件，因此冲突的可能性非常低。

有更好的想法吗？

编辑：我意识到我应该“对抗这个人”，但是已经有好几周了，FTP（可能是SFTP）还没有到位。因此，我正在寻找聪明的解决方案。我们行业的性质和我们正在开发的系统阻止了代码的第三方存储。是的，这是愚蠢和官僚主义的。它的方式：）

Answer 1

您可以双方使用git-svn并使用FTP连接同步/交换Git存储库。

Answer 2

为什么允许FTP服务器而不允许HTTP或SSH访问？

如果您担心安全问题，普通FTP肯定不会提供安全，而且SFTP无论如何都需要SSH，因此您可以使用SSH / SCP与存储库同步（这比Git更好用，而不是SVN，因为大多数版本控制任务吗）。

SVN可以通过HTTP轻松使用 - 为什么不只是每晚运行一次检查并将其放在每个人都可以访问的HTTP服务器上，在那里获取补丁，并且只有当你运行时才合并到一般工作的SVN存储库中就像你得到的补丁一样？

而且，不要打败死马，但Git非常值得投资转换。请考虑转换。

基本上，这种设置是不合情理的，你应该站出来实践它的那些没有思想的官僚并尝试找到一个可行的解决方案，你可以在这里直接分享一些版本控制机制，即使它们是'不是您的组用作主要源控制系统的第一级存储库。

Answer 3

如果你受限于FTP，我会回想你当前的想法。 FTP不是“实时”传输协议;无论传输的文件如何，你都需要在两端都有一个观察者注意到drop文件夹的变化。

如果您的付费客户制定了需要一点创造力的参与条款，那么就这样吧。如果出现错误，请使用svn diff，补丁，一些cron脚本和大量电子邮件通知。

过去与政府和大型企业实体合作过的任何人都会同情你的立场。事实上，有很多财富100强的公司出于充分的理由使用“投递箱模式”......它确实创造了一种间接攻击，可以对高目标或大容量网站有用。很烦人，是的，但是直到你走路一英里才真的值得推迟？毕竟，另一方面的开发人员可能对这些限制感到不满，但每个人都希望通过这些限制并尽可能地提供可用的代码。

为“未来项目......在适当的时刻”提出替代技术建议，但要满足当前项目的限制和要求。一旦您与客户建立了信誉，就可以更容易地提出将要采用的建议。

目前，您可以编写最好，最强大的基于FTP的SVN合并脚本......它会很有趣！

编辑：看来你并不孤单。我从来没有使用过这个项目，所以我不能相信它，但描述至少承认你的问题：svn2web。 “Subversion预提交或提交后挂钩，可用于通过sftp或ftp在相同或不同的服务器上复制已提交的文件。”

Answer 4

我处于类似情况，我们最终使用bazaar而不是subversion，因为它支持只使用FTP或SFTP读取/写入远程存储库（另一方面不需要客户端程序）端）。

你没有提到你的操作系统，但如果你正在使用Windows，那么bazaar会附带TortoiseBzr，如果你已经使用TortoiseSVN就会很熟悉。

Answer 5

我建议一些推迟。严格的IT策略的好处在于，通常这意味着有一个更新策略的既定流程。确定过程可能具有挑战性，特别是如果你还“打电话”（即你不能直接与其他人交谈）。

毫无疑问，源代码控制是最佳实践。禁止访问公共源代码控制存储库的策略不是最佳实践。仅提供源代码控制的中立第三方可能是最佳解决方案（“svn hosting”的大量点击）。您甚至可以通过Apache在端口80（或443）上安排svn托管...因此不需要进行防火墙调整。

我还建议PM为每个任务添加X分钟，因为没有共享源存储库的开销（甚至可能每周添加一次“修复源存储库任务”几个小时）。我当然会考虑花一些时间和精力来跟踪流程中涉及的工作量（如果流程每周只吃1小时，那仍然是一段重要的跟踪时间）。

另外......只是好奇......你会用这个方案运行一个持续集成服务器吗？也许我是悲观的，但是由于合并问题我会期待很多破坏的构建......而且每次它看起来都像是对方的派对错误。我想知道这个方案是否排除了CI（又一个最佳实践）？

Answer 6

他们似乎无法为您创建分支并让您访问该分支，这似乎很奇怪。这样，如果有任何问题，他们根本不需要合并你的分支。