Comment 7 for bug 185072

I think I understand the problem

Basically bzr assumes it can store the whole file in memory N times. This assumption is wrong.
I think that for binary files or basically for files > 32MB or so bzr should switch to streaming store method, without any compression.

This is much better than current situation because it will allow to store arbitrary stuff in .bzr which is what many people/companies need. Imagine a single tree for "project" that has ~10GB that is currently using p4. You cannot switch away from p4 because you cannot even store the _snapshot_ of that project into bzr without hitting this issue. Ideological statements such as "don't store binary stuff" don't help as the reality of existing projects cannot be altered easily.

I think there should be one big bug about this that can simply track all the other bugs that we have here (about memory consumption). I suspect that at least some of them are about storing large stuff in bzr. A separate issue should track events where bzr is not using streaming api and requires lots of memory to process/store/whatever regular source files with history.