代码之家  ›  专栏  ›  技术社区  ›  Steven Sproat

使用基于diff的补丁方法更新我的程序

  •  2
  • Steven Sproat  · 技术社区  · 15 年前

    目前,我的程序通过下载包含源代码的最新.tar.gz文件,并通过程序所在的当前目录将其解压缩来自我更新。更新有两种“模式”:一种是针对运行python源代码的用户,另一种是针对以windows exe运行程序的用户。

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

    我在想,一种更有效的方法是使用基于补丁/diff的系统,在该系统中,程序仅通过下载小的变更集,从一个版本增量更新到另一个版本。

    但是,我该怎么做呢?如果用户正在运行版本0.38,并且有0.42可用,他们是否下载0.38->39;0.39->40;0.40->41、0.41->42?如何处理二进制文件中的差异?(图片,在我的例子中)。

    我还需要维护一些包含所有补丁的存储库,这还不错。我只会在每个新版本中生成差异。但我想,对可执行文件执行此操作要比对纯Python代码执行此操作更困难?

    感谢您的任何意见。多谢。

    2 回复  |  直到 11 年前
        1
  •  3
  •   Alex Martelli    15 年前

    我建议,与其重新设计自己的更新管理系统,不如看看开源选项,例如 google updater (这是一年前公开采购的 Omaha )--我认为Windows Focus是可以的,因为您专门指的是Windows,但是如果您还需要Mac支持,中提供了类似的功能。 update engine (对于Linux,您可能希望使用特定发行版的包管理系统,而不是使用任何附加组件)。

    正如你将在 omaha overview ,重点不是确定和应用“delta”,而不是完全更新,而是为了用户的方便(以及安全性,当更新解决潜在的安全问题时),自动化过程。至于区别,我建议表现得类似于版本控制系统,比如 subversion (事实上,毫无疑问,您可以重用SVN的许多代码)--只有文本文件是不同的,二进制文件的“差异”是全部或全部(对于大多数二进制文件格式来说,如果有的话,在尝试发送少于整个新文件的过程中,如果完全改变了,那么获得的收益就太少了;尤其是对于图像,以及更普遍的各种压缩文件,通常情况下,底层内容的微小变化会对生成的文件产生巨大的变化)。

    如果您认为某些或所有二进制文件实际上可能会受益于使用差异和增量补丁的方法,而不是逐个文件替换全部或全部文件,那么我建议您首先尝试使用专门的实用程序,例如 jojodiff 为了验证——如果确实是这样(可能只针对某些文件,而其他文件也可能被完全替换),您可以用更新程序打包它的补丁部分(并将其作为python的子进程运行,等等)。

    至于在服务器上维护delta,一个混合的方法应该是有效的:即,当增量操作的优势变得太小而不能保证成本时,您将尝试保留所有(二次数)更新(从a a+1、a a+2、a+1 a+2等),但“切断”每个分支(有利于完全替换方法)。占用服务器上的存储空间和客户机上的处理时间(当然,除了启发式方法(也称为“尝试/实验并查看”),没有其他方法可以确定“太小”的阈值;-。

        2
  •  1
  •   Eli Bendersky    15 年前

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

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