Compressing the patch

[amlwwalker]

Hi,
I have been using bsdiff for a while, however it indexes the patch locations, which either takes a long time for larger files, or (which I've been doing) when I store the index so that I can easily retrieve it rather than generating it every time, It is absolutely massive on disk (~10X the size of the original file.

I am looking for a faster and quicker way to create diffs/patches as for my application they need to happen in (user) real time. I also don't want to have to store an index if I don't have to.

This library therefore looks very interesting. At first glance it also seems much faster. I have put a gist of my demo application using this library, here.

The issue I'm asking about then is the final size of the patch. My patches, using the above code, create patches that are basically identical to the size of the "to file", which in effect is no more efficient than creating copies of the file.

Looking at the original C implementation that I think this is based off, there is a compression option.

However it still seems like I am using it incorrectly, as I would have thought the patch would be just the difference between the original and the final anyway.

From my understanding and how I am using it in that gist is:

1. I create a file I want as the original (moon.png in my code)
2. I edit the original file and save that as (moon-to.png)
3. I specify the name for the patch (moon.patch)
4. I specify a location to save the applied version. I understand this is original+patch (i.e moon.png with moon.patch applied, giving me moon-to.png)
5. Run above code.

Am I doing something wrong here? The only thing I note is that you define a context in your full test, and I just use the context.Background()

Nice work, and thanks, any help working out why my patches are 100% the size of the resulting image would be great!

[fkollmann]

Hi Alex, the C implementation has built-in compression (if you compile it). However, the goal of the C implementation is to provide a "full-stack" patch tool. The go-xdelta library does not try to do this, but provides a dedicated layer for creating binary diffs. So the best way from my POV would be to simply wrap the writing of the patch file within a LZMA2 Writer. Best Regards, Felix

[amlwwalker]

Hi Felix, thanks so much for getting back to me. I'll look into this!

[fkollmann]

I am closing this ticket. Thanks for your feedback! Please feel free to reopen this ticket if needed.