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 relativel
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
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:
* 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;
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 t
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)
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 a
Hello,
On Sat, 4 Jan 2014 20:40:34 +0800
Anthony Towns 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 (eve
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:
>
>https://github.com/ajtowns/apt/t
On 4 January 2014 12:40, Anthony Towns 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
> "ooo, cool")
+++ 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")
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;
tho
12 matches
Mail list logo
