A more efficient up2date service using binary diffs

[Thomas Hille]

Am Dienstag, den 15.03.2005, 15:49 -0300 schrieb Alexandre Oliva:
> On Mar 14, 2005, Joe Desbonnet <jdesbonnet at gmail.com> wrote:
> 
> > Indeed there are serveral approaches to this problem, all with their
> > upsides and downsides. I'm currently treating the cpio archive as one
> > big file, and you're probably right -- treating it a  file system may
> > yield better results.
> 
> I doubt it.  In several cases, files get packaged in different
> directories or have names changed because of a version change, and
> then per-file deltas or rsync of individual files won't save you
> anything, but rsync of the entire archive will be able to pick up the
> unchanging bits.

But I don't think that changing names/paths occur that often (I may be
wrong here, but I doubt it). This could be tested out easily and a final
version might either decide wich of the two methods (single file or
multiple ones) to use on a per rpm basis or try to find the new name or
new location of the file. But that is the future, a simple
implementation would come first.

The other argument against using the whole rpm would be resources:
memory consumption is O(n) according to Joe's nice page with the test
results. And time is O((n+m) log n) according to the bsdiff site. And
having big packages like OOo or kernel reducing the input-file-size
would do a great job in reducing needed resources.

While I need say that I also see the problem of having to strip a nice
packaged rpm apart before doing the diff involves some more code in to
get the job done. Which in turn involves more errors.


Thomas