Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Yes it should have to look at every revision but it shouldn't have to load and hold every revision in memory at the same time. It seems like the max needed should be the sum of all the log messages + the largest revision patch (is that the correct term?) + some over head, which should be considerably smaller than the total ,v file size. Yes for smaller files loading the entire file into memory maybe convient and possibly faster but for larger files it just seems that your asking for a major slow down when you start using virtual memory Matt S. "Tony Hoyle" <tmh at nodomain.org> wrote in message news:d8d2lv$8p2$1 at paris.nodomain.org... > Victor A. Wagner Jr. wrote: > > > it doesn't have to be a binary file. I have a very large (1.2gb) file > > that's all text and has approximately 1000 changes in it that runs > > forever then gives an out of memory error. I have NO idea what memory > > is needed to produce a log and why it would be processing so much stuff. > > A log can use up a fair bit of memory as it has to load every single > revision, compared to a checkout that only typically needs one or two > revisions at a time. > > A worst case for a 1.2gb file would be 1.2gb of memory for the log, plus > a little extra. > > I actually did some work a while ago to reduce the memory requirement > for such things but I've no idea where that went to... it looks like it > never got committed. > > Tony