Subversion 可以取代 FTP 吗？答案

【问题标题】：Can Subversion replace FTP?Subversion 可以取代 FTP 吗？
【发布时间】：2013-01-15 15:17:55
【问题描述】：

我们目前使用 Subversion 来协调两个开发人员之间的网站开发。在我们之间，我们可能会处理一堆文件，检查我们的更改并使用 FTP 客户端以设定的时间间隔上传到生产服务器。

我觉得我在这里遗漏了一些明显的东西，但我们真的需要 FTP 吗？假设我们对存储库进行了一系列更改，有没有一种方法可以汇总从某个日期到现在发生更改的所有文件，然后将它们实时推送到包含生产站点的单独存储库？目前我们正在使用 SVN 日志查看哪些文件发生了更改，然后我们在 FTP 客户端中手动选择和上传。

我们处理的存储库已经在生产服务器上，只是不在 IIS 为运行站点而引用的文件夹中。

任何想法都将不胜感激！

编辑 1 月 16 日 ------------------------------

Subversion 的 FTP 插件怎么样，以便我可以进入“日志消息”区域识别在给定时间段内发生更改的文件，选择它们并将 FTP 用于生产？有这样的工具吗？

顺便说一句：这里有很多有用的cmets，谢谢大家的贡献。

【问题讨论】：

如果您只是在谈论源代码，那么是的，SVN 服务器可以取代 FTP。但是，源代码控制从未真正适用于大文件（例如视频文件、数据库备份等）。
SVN是版本控制系统，不是普通的FTP存储！
我们不处理任何大于 500kb 的文件。我想我的问题真的应该是“使用 SVN 将内容移动到生产服务器作为 FTP 的替代方案是常见的做法吗？”

标签： svn ftp repository branch

【解决方案1】：

如果您使用 FTP 来回推送编程更改，那么最好使用像 Subversion 这样的版本控制系统。 Subversion 不仅处理最新代码问题，而且处理你们两个同时更新同一个文件的情况。此外，它还为您提供版本历史记录，因此您可以查看随时间发生的变化以及原因。

当您在开发人员之间共享库对象（.jar 文件、.dll、.so 等）时，FTP 非常有用。没有可以从文件中提取的相关开发历史记录，并且您不会直接修改这些文件。此外，这些文件会很快老化、过时，并在您的存储库中占用大量空间。

小心使用 FTP。这不是一个安全的协议有人监听可以收集密码。请改用 SCP 或 SFTP。这些与sshd 守护进程有关，所以如果你有能力使用ssh，你可能可以设置scp 和sftp。

除了使用 FTP，另一种可能性是使用Dropbox 或等效程序来共享这些文件。 Dropbox 会自动更新所有开发人员之间的文件，因此他们不必记住他们是否获取了最新代码。另外，还有一些版本控制方面。您可以查看一些版本历史记录，甚至可以获取文件的旧版本。 Dropbox 是安全的，所有传输都经过加密。 Dropbox 服务器上的文件甚至是加密存储的（尽管 Dropbox 本身确实保留了解密这些文件的密钥，因为它能够在用户之间共享文件）。

【讨论】：

请从不建议 Dropbox 在真正需要 SCM 的时间和地点替代 SCM！
@LazyBadger 我不推荐 Dropbox 作为 SCM 的替代品，而是作为 FTP 的替代品。我会在我的回答中澄清这一点。
Dropbox 不是一个好的解决方案。它不跟踪版本历史，不允许你比较更改，如果两个人同时更新同一个文件，你就完蛋了。
正如我向 LaxyBadger 解释的那样，我推荐 Dropbox 作为 FTP 替代品，而不是 SCM 替代品。 FTP 不安全，需要服务器。他们不应该在 Subversion 中存储构建的对象（*.dll、*.jar、*.so、*.a）文件。

【解决方案2】：

当您想要将文件来回发送到您的服务器而不一定需要通过版本控制时，FTP 或 SCP 仍然很方便。 Subversion 是一种版本控制工具，不应用作未版本化文件的传输渠道。所以我的回答是你应该保留两者。

【讨论】：

您可能希望从服务器获取到本地计算机的未版本控制文件的一个示例是日志文件，以防您想要筛选和分析它们，或者可能通过电子邮件发送它们。显然，您不应该将它们签入服务器上的 SVN，然后在本地签出——那是愚蠢的

【解决方案3】：

首先：您必须了解差异，切勿将源代码控制管理和部署管理混为一谈——它们是不同的任务和工作，由不同的工具执行。

虽然 SCM 可以（以某种方式）用作部署工具，但由于 SCM 在此（部署）领域的限制，这并不常见。

回到你的问题。

如果您的 RepoServer 和 ProdServer 是不同的主机，您可以使用它们支持的 any 底层传输。 FTP（如果您有选择）不仅来自安全 POV，而且还来自可能的灵活性 - 将 some tree 上传到目标的常见任务对于纯 FTP、FTP 来说并不容易和透明会话的自动化程度很差。恢复 - 如果您可以使用其他传输，您至少可以尝试将您的部署过程用于其他传输。

【讨论】：

【解决方案4】：

FTP 是传输文件的好方法。这就是它的目的。 SCM 用于管理源代码。您需要一些部署管理，如果可能的话，它应该是自动化的。如果是我，我会编写一个脚本来从 svn 获取更改的文件并自动通过 SFTP 或 FTPS 部署它们。每次都以相同方式进行部署的脚本是理想的。

您也可以查看 rsync。它速度快，发送差异，而且安全。

根据我的经验，当您将大型文件（例如 VM 图像或视频）添加到源代码管理时，会减慢开发速度，尤其是在您创建分支或将 repo 拉到新盒子时。

另一位贡献者建议将 Dropbox 用于 SCM 和部署管理。我不喜欢 Dropbox 的源代码。它不提供您将习惯来自 SVN 的合并功能。我在生产环境中使用 Dropbox 进行廉价的自动备份。我让 WHM/Cpanel 将备份放在 Dropbox 文件夹中。请务必关闭网络同步，因为大多数数据中心不喜欢 UDP 数据包在内部网络中传输。

【讨论】：

【解决方案5】：

是的。你的问题的答案是肯定的。 Subversion 可以替代 FTP。

【讨论】：

【解决方案6】：

我找到了你的英雄： Bazaar 是一个分布式版本控制系统，可以轻松进行协作开发。 Bazaar 的优势之一是它对不同工作流程的适应性。您可以选择：集中式工作、分布式工作或介于两者之间的任何工作他的优势在于它能够使用 FTP 或 SFTP 读取/写入远程存储库（无需另一端的客户端程序）

我觉得svn2web也可以！

【讨论】：