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 ] 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. There is no fallback from client-side to server-side in case the previous one fails: It is just assumed that pdiffs are bad in this case and we proceed with the download of the complete indexes. (could be done if really needed, but I doubt it is because:) I have no knowledge about other implementations of server-merge and somehow I doubt there are any, but if there are and they have similar fields I am happy to detect it as well – otherwise they should just add this field and be done. The alternative of using a new field for client-merge kinda sucks and big changes to the diffIndex format will probably take a little while longer to discussed/implemented/adopted. (It's not that I personally like the field name, but it is used in the wild and documented(!), so why not.) Many questions remain, but I guess we are better off carrying this over to debian-dak@l.d.o² as d-d@ is usually not so talkative if native tools are the topic (q.e.d.). Are you maybe willing to drive this, Anthony? I have the feeling that there is a lot to be talked about in the area of pdiffs but nobody so far had the energy to get it really started. Best regards David Kalnischkies ¹ as documented in https://wiki.debian.org/RepositoryFormat ² "we" "agreed" some time ago that this is the right list for changes to the repository format effecting possibly all clients/servers.
Attachment:
signature.asc
Description: Digital signature