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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140120192156.ga27...@master.debian.org
