目前我的程序通过下载包含源代码的最新.tar.gz文件并在程序所在的当前目录中提取它来更新自身。有2种“更新模式” - 一种用于运行Python源的用户，另一种用于将程序作为Windows exe运行。
随着时间的推移，由于新的图像，库，文档和代码，每个版本的程序文件大小都会变得越来越大。但是，有时只有代码更改从一个版本发生到另一个版本，因此当只有很少的代码更改时，用户会一遍又一遍地重新下载所有图像，文档等。
我认为更有效的方法是使用基于补丁/差异的系统，程序通过仅下载小的更改集来逐步将自身从一个版本更新到另一个版本。
但是，我应该怎么做？如果用户运行版本0.38，并且有0.42可用，他们是否下载0.38-> 39; 0.39-→40; 0.40-> 41,0.41-> 42？我如何处理二进制文件的差异？ （图片，在我的情况下）。
我还必须维护一些包含所有补丁的存储库，这不是太糟糕。我只是为每个新版本生成差异。但我想对可执行文件执行此操作比对纯Python代码更难？
感谢任何输入。非常感谢。
答案 0 :(得分：3)
我建议您不要重新发明自己的更新管理系统，而应该查看开源选项，例如google updater（一年前开源为Omaha） - I想象一下Windows焦点是正确的，因为你专门引用了Windows，但是如果你还需要Mac支持，update engine中提供了类似的功能（对于Linux，你可能想要使用特定发行版的包管理系统而不是使用任何附加的一个。）
正如您在omaha overview中看到的那样，重点不在于确定和应用“增量”而非完整更新，而是专注于自动化流程以方便用户（以及安全性，当更新解决潜在问题时）安全问题）。至于差异，我建议行为类似于版本控制系统，如subversion（实际上，你可以毫无疑问地重复使用svn的大部分代码） - 只有文本文件才有区别，二进制文件的“差异”都是 - 或者什么都没有（对于大多数二进制文件格式来说，如果有的话，增加的数量太少 - 如果有的话 - 试图发送少于整个新文件的内容，如果有的话，那就更改;特别是对于图像，以及更常见的各种压缩文件，通常，底层内容的微小变化会在生成的文件中产生巨大的变化。）
如果您认为部分或全部二进制文件实际上可能会受益于使用差异和增量补丁的方法，而不是全部或全部替换文件，我建议您首先尝试使用专门的实用程序，例如jojodiff要验证 - 如果情况确实如此（可能仅针对某些文件，而其他文件也可能完全替换），您可以使用更新程序将其补丁部分打包（并将其作为来自Python的子进程等。）
至于维护服务器上的增量，混合方法应该有效：即，你会尝试保留所有（二次数）更新（从A→A + 1，A→A + 2，A + 1） →A + 2等）但是当切换的优势变得太小而无法保证在服务器上占用存储空间以及处理服务器上的处理时间时，“切断”每个分支（有利于完全替换方法）客户（当然，只有启发式，即尝试/实验，看看，确定“太小”的门槛; - ）。
答案 1 :(得分：1)
您的更新管理员可以知道当前应用的版本，以及最新版本的版本，并仅应用相关的修补程序。
假设用户运行0.38，目前有0.42可用。 0.42的更新包含0.39,0.40,0.41和0.42的补丁（可能还有更远的历史记录）。更新管理器下载0.42更新，知道它为0.38并应用所有相关补丁。如果它当前运行0.41，它只应用最新的补丁，依此类推。