使用基于差异的补丁方法更新我的程序答案

【问题标题】：Updating my program, using a diff-based patch approach使用基于差异的补丁方法更新我的程序
【发布时间】：2010-07-10 15:25:02
【问题描述】：

目前，我的程序通过下载包含源代码的最新 .tar.gz 文件进行自我更新，并将其解压缩到程序所在的当前目录中。有两种更新“模式”——一种用于运行 Python 源的用户，另一种用于用户将程序作为 Windows exe 运行。

随着时间的推移，由于新的图像、库、文档和代码，我的程序的文件大小随着每个版本的发布而变得越来越大。但是，有时从一个版本到另一个版本只发生代码更改，因此用户最终会一遍又一遍地重新下载所有图像、文档等，而只有很小的代码更改。

我在想一种更有效的方法是使用基于补丁/差异的系统，在该系统中，程序仅通过下载小的更改集即可将自己从一个版本增量更新到另一个版本。

但是，我该怎么做呢？如果用户正在运行 0.38 版本，并且有 0.42 可用，他们是否下载 0.38->39？ 0.39->40； 0.40->41, 0.41->42？我将如何处理二进制文件中的差异？（图像，在我的情况下）。

我还必须维护一些包含所有补丁的存储库，这还不错。我只是在每个新版本中生成差异。但我想对可执行文件执行此操作比对纯 python 代码执行此操作更难？

感谢任何输入。非常感谢。

【问题讨论】：

标签： python diff patch

【解决方案1】：

我建议，与其重新发明自己的更新管理系统，不如看看开源选项，例如 google updater（一年多前以 Omaha 开源）——我想是 Windows 的焦点没关系，因为您确实特别提到了 Windows，但如果您还需要 Mac 支持，update engine 中提供了类似的功能（对于 Linux，您可能希望使用特定发行版的包管理系统，而不是使用任何附加组件） .

正如您将在 omaha overview 中看到的那样，重点不是专门确定和应用“增量”而不是完整更新，而是为了用户的方便（和安全性，当更新解决潜在的安全问题时）自动化流程）。至于差异，我建议表现得类似于 subversion 之类的版本控制系统（事实上，您可以毫无疑问地重用 svn 的大部分代码）——只有文本文件不同，二进制文件的“差异”是全或-什么都没有（对于大多数二进制文件格式，如果有的话，尝试发送少于整个新文件（如果有的话）的收益太少了；特别是对于图像，以及更普遍的各种压缩文件，这是典型的底层内容的微小变化可能会在结果文件中产生巨大的变化）。

如果您认为您的部分或全部二进制文件实际上可能受益于使用差异和增量补丁的方法，而不是全部或没有逐个文件替换，我建议您首先尝试使用专门的实用程序，例如jojodiff 进行验证 - 如果确实如此（可能仅适用于某些文件，而其他文件也可能被完全替换），您可以使用更新程序打包它的补丁部分（并将其作为子进程从Python 等）。

至于在服务器上维护增量，应该采用混合方法：即，您会尝试保留所有（二次）更新（从 A → A+1、A → A+2、A+1 → A+2 等），但是当增量做事的优势变得太小而无法保证在服务器上占用存储和处理时间的成本时，“切断”每个分支（有利于完全替换的方法）客户端（当然，只有启发式方法，也就是尝试/实验和查看，以确定“太小”的阈值；-)。

【讨论】：

将程序保存在 Mercurial 存储库中不是一件简单的事情吗？
@jsbueno，当然，您可以在更高的抽象级别（而不仅仅是复制和重新利用点点滴滴），但是与应用程序本身相比，与您的应用程序并排安装完整的客户端（取决于应用程序的大小）可能会占用大量空间。（与 svn 等经典 vcr 相比，这里的分布式 vcrs 没有通常的优势，因为您确实希望将您的服务器用作“主”树，不关心允许本地分支/多个头等） .

【解决方案2】：

您的更新管理员可以知道当前应用程序是哪个版本，哪个版本是最新的，并且只应用相关补丁。

假设用户运行 0.38，当前有 0.42 可用。 0.42 的更新包含 0.39、0.40、0.41 和 0.42 的补丁（可能更远的历史）。更新管理器下载 0.42 更新，知道它是 0.38 并应用所有相关补丁。如果它当前运行的是 0.41，它只会应用最新的补丁，依此类推。

【讨论】：