ah, no, I meant the strictly append-only header stuff. Back when there was a discussion on how to be sure a discovered header was a real header and not a carefully crafted attachment.
B. On Tue, Jan 26, 2010 at 5:13 PM, Robert Newson <[email protected]> wrote: > I vaguely recall this came out when Damien added deterministic revisions? > > On Tue, Jan 26, 2010 at 3:28 PM, Filipe David Manana <[email protected]> > wrote: >> Yep, it makes sense. >> >> For text files, with a level 8 compression, I've been seeing attachments >> being reduced to 30-40% of their original size, which is fairly positive :) >> >> On Tue, Jan 26, 2010 at 4:25 PM, Paul Davis >> <[email protected]>wrote: >> >>> > How did you do the tests? Some tool to measure the speed? >>> > It would be interesting to do the same for the attachments. >>> > Personally I think that for text mime types, it's generally worth doing >>> the >>> > compression. >>> >>> They weren't very scientific. Generate a view with and without and >>> measure the time and file size for each. >>> >>> Not at all saying we shouldn't be using it for the attachments. I was >>> thinking that now that we are doing attachment encoding proper that it >>> would've been better to turn of the attempt to compress each >>> compressed chunk because that's just wasted effort. For attachments it >>> makes much more sense to do it like your patch because of the gzip >>> dictionaries will run over the stream and not just each chunk written >>> to disk. If that makes sense? >>> >>> Paul >>> >> >> >> >> -- >> Filipe David Manana, >> [email protected] >> PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." >> >
