revlog: break up compression of large deltas Python's zlib apparently makes an internal copy of strings passed to compress(). To avoid this, compress strings 1M at a time, then join them at the end if the result would be smaller than the original. For initial commits of large but compressible files, this cuts peak memory usage nearly in half.

revlog: fix caching of buffer objects

chunkiter: handle large reads more efficiently - for large reads, don't attempt to read more than necessary - if we've gathered the exact number of bytes needed, avoid a string copy

revlog: avoid large yields in group() Split large yields so that the downstream consumer (chunkbuffer) will avoid some pain when reading ahead.

chunkiter: simplify iter logic

chunkbuffer: removed unused method and arg

revlog: reduce memory usage in addgroup - use a buffer to extract the delta from a chunk - avoid concatenating to a compressed delta - use a buffer to directly extra full text from a trivial delta - delete chunk and delta objects after use

mpatch: allow buffer objects for input

Merge with crew Those crew folks are getting lazy about pulling from upstream before committing.

Merge with crew

Merge with -stable

findcopies: fix rename bug We've fiddled with this line several times, and an old bug has reappeared from it. Let's take a peek at the history. The original "or" (rev 3674, in 0.9.2 and 0.9.3): http://www.selenic.com/hg/rev/9103dab96093 Then I changed it to an "and" to fix a bug (rev 4304): http://www.selenic.com/hg/rev/4787e2b0dd03 Then for reasons now lost in the mists of time, I dropped half (rev 4399): http://www.selenic.com/hg/rev/93652499bed3 Then we added back the "or" (rev 4416, in 0.9.4): http://www.selenic.com/hg/rev/bb1800a7d7e1 So it seems it ought to be "and".