jzebedee / deltaq Goto Github PK

Google's open-vcdiff is the best open implementation of VCDIFF I've found so far. It's licensed under Apache 2.0 so there won't be any issues with the ported code. Porting it over should be the first step in making a working VCDIFF encoder, which nobody seems to have the stomach for yet. 😨

xdelta is the big dog in handling VCDIFF and xdelta3 has a few extensions to the format which help it along. I don't think we're going to get anything close to their performance, but it's the benchmark once we have a minimum working implementation.

I've written a server-side .NET core app using this library to produce diff files that are later applied using a Java extension for Maven using jbsdiff library. The idea is to produce a diff for two Maven artifact versions and thus reduce the download required by each developer.

The problem I've run into is that the end file was simply wrong (good thing Maven verify sha1).
I can provide example files if you want or any other detail to help.

Is there any reason that the patch file of this library will not be compatible with the other library?

What is the matter with the Bzip2 implementation since the stream isn't seekable but the BsDiff-class requires a seekable stream? Is this for the planned upcoming VCDIFF implementation?

Looks like you gave up with those PR's on the BsDiff project and decided to fork it into deltaq under your own control. Fair play :)

So is this assumed to be the successor to BsDiff, with those annoying sorting bugs fixed, and other subtle improvements?

I am hooking this thing up to my Xamarin project right now, looking forward to cutting down my app's server<->client bandwidth usage very significantly.

We're finding that occasionally the delta generator gets stuck on particular files - most complex deltas finish within a few minutes, but in this case I've left it running overnight without result.

It spends hours at a time inside the "for (var scsc = scan += len; scan < newData.Length; scan++)" loop. It seems like the algorithm does progress (as occasionally that loop finishes, and then goes round the while loop again).

The problematic files are both 32MB in size and feature sporadic differences where individual bytes have been changed. I can provide a sample if it'd be useful, but I'm mostly wondering if this is something you've seen before?