Account Options

  1. Sign in
Google Groups Home
« Groups Home
Trac Development
Home
+ new post
About this group
Join this group
View this group in the new Google Groups
Message from discussion More Runaway Trac Process
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Christian Boos  
View profile  
 More options Jan 14 2009, 9:59 am
From: Christian Boos <cb...@neuf.fr>
Date: Wed, 14 Jan 2009 15:59:08 +0100
Local: Wed, Jan 14 2009 9:59 am
Subject: Re: [Trac-dev] Re: More Runaway Trac Process
Print | View thread | Show original | Report this message | Find messages by this author

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 must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google