On Mon, Jan 20, 2014 at 07:21:56PM +, Anthony Towns wrote:
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
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
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
Hi!
(I think a nice efficient compromise method would be Patch-Step-Size:
8 8 4 4 4 4 2 2 1, which would only update a lg(diffs) each time you
updated the packages file, and only require users to download and
apply a maximum of lg(diffs) to get up to date)
Thank you, better pdiff handling is
On 2014-01-05 11:40, Vitaliy Filippov wrote:
Hi!
(I think a nice efficient compromise method would be Patch-Step-Size:
8 8 4 4 4 4 2 2 1, which would only update a lg(diffs) each time you
updated the packages file, and only require users to download and
apply a maximum of lg(diffs) to get
Server-side? Don't know - but client-side merging is not difficult (and
implementations of it exists already now), so if this is a problem
server-side, my personal recommendation would be to do merging only on
the client side.
I've asked this after reading Anthony's message where he says:
(I
* Anthony Towns:
Some time ago (*cough* 2009), I had a play with working out how to
apply pdiffs more efficiently than apt currently does, and implemented
a proof of concept in python [0]. There weren't any replies (even a
ooo, cool) when I posted to the deity list, so I left it at that;
Salut tout le monde,
Some time ago (*cough* 2009), I had a play with working out how to
apply pdiffs more efficiently than apt currently does, and implemented
a proof of concept in python [0]. There weren't any replies (even a
ooo, cool) when I posted to the deity list, so I left it at that;
+++ Anthony Towns [2014-01-04 20:40 +0800]:
Salut tout le monde,
Some time ago (*cough* 2009), I had a play with working out how to
apply pdiffs more efficiently than apt currently does, and implemented
a proof of concept in python [0]. There weren't any replies (even a
ooo, cool)
On 4 January 2014 12:40, Anthony Towns a...@erisian.com.au wrote:
Salut tout le monde,
Some time ago (*cough* 2009), I had a play with working out how to
apply pdiffs more efficiently than apt currently does, and implemented
a proof of concept in python [0]. There weren't any replies (even a
Hi,
I had a go on this topic as well in early december, but got distracted
which will be for a bit longer still, so just as a somewhat short reply:
On Sat, Jan 04, 2014 at 08:40:34PM +0800, Anthony Towns wrote:
My patched apt source is up on github at:
Hello,
On Sat, 4 Jan 2014 20:40:34 +0800
Anthony Towns a...@erisian.com.au wrote:
Salut tout le monde,
Some time ago (*cough* 2009), I had a play with working out how to
apply pdiffs more efficiently than apt currently does, and implemented
a proof of concept in python [0]. There weren't
12 matches
Mail list logo
