[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 


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

It looks to me like dak and reprepro are the only tools that generate
pdiffs currently, fwiw.


Reply to: