目前，我的程序通过下载包含源代码的最新 .tar.gz 文件进行 self 更新，并将其解压缩到程序所在的当前目录。有两种更新“模式”——一种用于运行 Python 源代码的用户，另一种用于用户将程序作为 Windows exe 运行。
随着时间的推移，由于新的图像、库、文档和代码，我的程序的文件大小随着每次发布而变大。然而，有时从一个版本到另一个版本只发生代码更改，因此用户最终会一遍又一遍地重新下载所有图像、文档等，而实际上只有很小的代码更改。
我在想一种更有效的方法是使用基于补丁/差异的系统，在该系统中，程序仅通过下载小的更改集来逐步将自身从一个版本更新到另一个版本。
但是，我应该怎么做呢？如果用户运行的是 0.38 版本，并且有可用的 0.42，他们是否下载 0.38->39； 0.39->40； 0.40->41，0.41->42？我将如何处理二进制文件中的差异？ (图像，在我的例子中)。
我还必须维护一些包含所有补丁的存储库，这还不错。我只是在每个新版本中生成差异。但我想对可执行文件执行此操作比对纯 Python 代码执行此操作更难？
欢迎任何意见。非常感谢。
最佳答案
我建议与其重新发明自己的更新管理系统，不如看看开源选项，例如 google updater (一年多前以 Omaha 的形式开源)——我认为 Windows 焦点是可以的，因为您确实专门提到了 Windows，但如果您还需要 Mac 支持，update engine 中提供了类似的功能。 (对于 Linux，您可能希望使用特定发行版的包管理系统，而不是使用任何附加组件)。
正如您将在 omaha overview 中看到的那样，重点不是专门确定和应用“增量”而不是完整更新，而是为了用户的方便(和安全性，当更新解决潜在的安全问题时)自动化该过程。至于差异，我建议表现得类似于 subversion 等版本控制系统。 (事实上，你可以毫无疑问地重用 svn 的大部分代码)——只有文本文件是不同的，二进制文件的“差异”是全有或全无(对于大多数二进制文件格式来说， yield 太少了——如果有的话——在尝试发送少于整个新文件的情况下，如果根本没有改变；特别是对于图像，以及更普遍的各种压缩文件，通常情况下，基础内容的微小变化会导致结果文件发生巨大变化)。
如果您认为您的部分或全部二进制文件实际上可能受益于使用差异和增量补丁的方法，而不是逐个文件替换全部或全部，我建议您首先尝试使用专门的实用程序，例如jojodiff验证——如果确实如此(可能只针对某些文件，而其他文件也可能被完全替换)，您可以将它的补丁部分与您的更新程序打包在一起(并将其作为 Python 等的子进程运行) ).
至于在服务器上维护增量，混合方法应该有效:即，您将尝试保留所有(二次数)更新(从 A → A+1、A → A+2、A+1 → A+2 等)，但当增量做事的优势变得太小而无法保证在服务器上占用存储空间和处理时间的成本时，“切断”每个分支(支持完全替换方法)客户端(当然，只有启发式方法，也就是尝试/试验并查看，以确定“太小”的阈值；-)。
关于python - 使用基于差异的补丁方法更新我的程序，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3219772/