David Abrahams wrote: > on Thu Jan 08 2009, David Abrahams <dave-AT-boostpro.com> wrote: > > >>> Have a look at http://trac.edgewall.org/wiki/TracIni#changeset-section >>> and reduce the number of max. files (e.g. 500). Does the problem still >>> happen? >>> >> Hmm, good question. >> >> svn diff -r 2791:2796 | grep -cE '^======================' >> >> says there are around 1929 files. OK, dropping the number to 500... >> >> ...works! >> > > Couldn't Trac better protect itself from this sort of thing by using a > timeout? It could simply bail on inlining anything if it takes more > than X seconds. That way, one wouldn't have to try to guess at the > number of files or bytes that will cause an apparent hang on particular > hardware and source bases. >
Probably a timeout-based approach can work, yes. Besides we can still optimize _content_changes further and especially the way it takes care of big files: - instead of reading all the content of the old and new files before checking if any of those is binary, it could take this decision by looking at the extension or at the first 1000 bytes, as #3332 did IIRC. - don't display in-line changes for big files (> 100k?) at all, even if they're not binary, except of course when viewing a changeset restricted to that file -- Christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
