There are a couple of “update maker” apps for Windows that do exactly what you want … they’re often used by PC game vendors distributing updates. I haven’t heard of a Mac version of any of them.

0.0 —> 0.1 —> 1.0 —> 1.1 —> 2.0

The arrows denote the patches I’ve already released, which are built using Package Maker and essentially include an entire copy of the files that have changed. These are huge. I’d like to release a single update to update everything up to the latest respective version. One thing I’ve considered is to create several diffs:
diff0.0-0.1, diff0.1-1.0, diff1.0-1.1, diff1.1-2.0

Then my update will consist of applying these diffs in succession. The diff technology needs to be able to update an entire tree and needs to succeed even for a partial tree. What that means is that if someone removed a file foo.txt from their install, what they should end up with is version 2.0 without the file foo.txt. Also, this should work regardless of what version you have right now so applying diff0.0-0.1 to someone who has 0.1 or 1.0 should do nothing.

I started looking at rsync yesterday and it appears to do exactly what I want. I have run into several bugs in the version of rsync that’s shipped with Leopard but I suppose I could always ship a newer version of rsync with my updater. I’m going to continue investigating rsync.

My question is: Are there any other binary diff technologies that I should consider? Using rsync seems a little like using a battle tank to flatten a house - it will do the job but is not exactly what it was designed to do.

how is version control unreliable? Things like this are well within the primary use of version control (i.e. distributing only the small deltas when something changes so as to not have to upload/download the entire blob of data).

Breaking the file into parts does nothing to solve the problem, unless the parts are small enough, or the changes localized enough that most of the parts do not have to be redownloaded. After implementing the code to decide which parts to download, and which parts to not dlownload, you’ve basically reinvented the wheel.

Apple themselves point out you can patch the signature file itself (http://developer.apple.com/documentation/Security/Conceptual/CodeSigningGuide/Procedures/chapter_3_section_5.html). So code signing should, as Daniel said, not be a problem.

That said, bending a version control system to update an app doesn’t seem like a great win for me. You don’t need merge tracking, shelving, cloning, pushing and could even go without history. All most apps need is a simple stack of binary diffs, treated like an Undo/Redo queue or even just a Redo queue. Seems like, compared to getting a SCM system updating seamlessly and efficiently, that’s not such a big deal.

Thanks,

Thanks,

I think the idea is nice, but I would rather prefer a straightforward system of doing things:

1. In configuration give the app a server and name of RSS file describing new versions.
2. the app automatically check and download needed update files.
3. automatically unpack the download
4. automatically run a script altering the app tree if needed and applying binary or any other diffs in any format you want (e.g. bsdiff - a great tool for small binary diffs)

Updating from v1.0 to 1.5 will go something like download update to 1.1, 1.2, 1.3, 1.4, 1.5 and run all the scripts in that order. I know it doesn’t support downgrades, but e.g. with antivirus software, downgrade is a thing you really don’t want to let your customers do.

I think using svn, rsync or whatever can be difficult for the software providers. Suppose you have a product used by millions of users that need update every day (e.g. antivirus again). Running own reliable rsync server is really a complicated task.

On the other hand, there are some providers (e.g. akamai), who are specialized for this and can make your updates available to the world reliably. But these companies are billing you for a megabytes of data downloaded from their servers. So you just want to post there update files as small as possible and not to deploy a whole rsync server.