On Wed, Nov 25, 2009 at 08:08:36PM +0100, David Kalnischkies wrote: > Really, i don't think it is a stackoverflow as it fails at a to prominent > cmd count... I have rewritten a few parts of rred to use long and more > sane return values and it patches the file now just fine. :) ok, excellent. but didn't someone say ulimit -s fixes it? > While on it i have also integrated #463354 which will speed up the > patch-process a bit (but don't expect a miracle, the biggest timesucker > still is the decompression of the patches and applying them patch by > patch instead of concatenate the patches - but this has again a few > problems as this is far from a simple cat operation as you have to > recalculate line numbers) #463354 looks like it is also getting rid of the recursion, that is very good! > I will tell you a secret: For most users with fast connections pdiffs > are (always) slower. Pdiffs fight against download size and > ... heh, i know! > Michael has already a patch for apt to don't download the patch > if the patch is bigger than the actual file, so no need to implement > some logic in the generator as the file was itself correct, just to > big to be useful. cool, but i thought there is already logic to do that in the generator, plus changing the generator not to produce uselessly large files would also autmagically fix the whole problems for systems with an older apt that still contains the broken rred... cu robert -- Robert Lemmen http://www.semistable.com
Attachment:
signature.asc
Description: Digital signature