Re: Better pdiff handling for apt
On Fri, Jan 17, 2014 at 04:13:34PM +0100, David Kalnischkies wrote:
> On Sat, Jan 04, 2014 at 07:34:07PM +0100, David Kalnischkies wrote:
> > So, I guess merging both could cross a lot of points of your list and
> > be relatively easily feed into unstable for proper field-testing.
> > (a upload of my part was planed as a christmas present to experimental,
> > but as usual: If you want to make deity laugh, tell her your plans)
> I just did this merging the other day and Michael pushed it to experimental
> (again), so everyone should feel free to give it a spin, you might be in
> for a pleasant surprise ??? depending on how much you trusted the
> "benchmark" in my previous mail.
> [technical, it was indeed as easy as using my POC and Anthonys rred and
> put some minor glue between them ??? very nice :D ]
Very nice indeed.
There's an extra patch at
https://github.com/ajtowns/apt/commits/better-pdiffs-dk
that makes a couple of minor cleanups in rred.cc. I think there's a few
more to do, but I got confused as to how the pkgAcqIndexMergeDiffs stuff
works, and will need to print that out to grok it, I expect...
> Breakage potential:
> I decided for now to enable client-side merge by default but with
> detection for the X-Patch-Precedence field reprepro has introduced?? if it
> has merged patches on the server side, which falls back to the old
> handling.
Ah, nice, that seems like it should make it backwards compatible in
practice.
It looks to me like dak and reprepro are the only tools that generate
pdiffs currently, fwiw.
Cheers,
aj
Reply to: