4 ms·

You mentioned storing diffs against every previous version. In principle, couldn't you, when a new package is pushed to the repository: 1. Diff against the pre

by rjh29 15y ago

You mentioned storing diffs against every previous version. In principle, couldn't you, when a new package is pushed to the repository: 1. Diff against the previous version and store the diff. 2. Delete the previous version. You could upgrade from any previous version by applying all the diffs in sequence, and you only need to keep one full version around. You could also discard diffs after a certain date because, as you point out, the worst case is that the full version is used instead. I guess this would increase disk space for the mirrors, but even 100GB wouldn't be a lot of disk space, and the savings for (presumably more expensive) internet data transfer would be a lot bigger?

nuclear_eclipse 15y ago
> You mentioned storing diffs against every previous version I didn't say you need to. Eg, with my software project, I wrote an update system that supported diff upgrading against the two latest versions, and anyone still running an older version had to download a full update. > You could upgrade from any previous version by applying all the diffs in sequence At that point you also need to make sure that you aren't downloading more in the process of applying a series of patches than you would need to download for a full update, which also means you need to start being aware of multiple update options, which balloons the complexity of your update code.
- true_religion 15y ago
  > At that point you also need to make sure that you aren't downloading more in the process of applying a series of patches than you would need to download for a full update Well you wouldn't really need to but it would be a good sanity check on the client side. The common case could be that people are simply keeping up with the stable edge w/o patching binaries themselves out of band---that's the case with some desktop linux variants.
- leif 15y ago
  > At that point you also need to make sure that you aren't downloading more in the process of applying a series of patches than you would need to download for a full update, which also means you need to start being aware of multiple update options, which balloons the complexity of your update code. The obvious way to handle this is to store full package "snapshots" on "major" version releases (probably upstream releases for packages with lots of local patching, or "one level up from the bottom" releases) and diffs in between. That is not a lot of code if you already have a sane way of managing release numbers within your package manager, which you hopefully do.

by rjh29 15y ago

nuclear_eclipse 15y ago

> You mentioned storing diffs against every previous version I didn't say you need to. Eg, with my software project, I wrote an update system that supported diff upgrading against the two latest versions, and anyone still running an older version had to download a full update. > You could upgrade from any previous version by applying all the diffs in sequence At that point you also need to make sure that you aren't downloading more in the process of applying a series of patches than you would need to download for a full update, which also means you need to start being aware of multiple update options, which balloons the complexity of your update code.

true_religion 15y ago
> At that point you also need to make sure that you aren't downloading more in the process of applying a series of patches than you would need to download for a full update Well you wouldn't really need to but it would be a good sanity check on the client side. The common case could be that people are simply keeping up with the stable edge w/o patching binaries themselves out of band---that's the case with some desktop linux variants.
leif 15y ago
> At that point you also need to make sure that you aren't downloading more in the process of applying a series of patches than you would need to download for a full update, which also means you need to start being aware of multiple update options, which balloons the complexity of your update code. The obvious way to handle this is to store full package "snapshots" on "major" version releases (probably upstream releases for packages with lots of local patching, or "one level up from the bottom" releases) and diffs in between. That is not a lot of code if you already have a sane way of managing release numbers within your package manager, which you hopefully do.