On Fri, 2006-03-17 at 13:26 -0600, Russ Brown wrote: > > > > What would be very valuable here is to know what was the last revision > > for which the timeline was 'fast'. > > You could setup a test server on the same repos that is showing the pb, > > then do a dichotomic search to find the culprit rev. > > > > Due to the wonders of bash command line history, I can report that the > previous revision we were running against was 2651. > > Are there any problems with running a version of the code that is older > than the trac database it is being run against? If not I can try > switching back to an older rev and seeing if that resolves the problem. > As you say I can then experiment with the revision until I find the one > at which things slow down at. > > Thanks. > >
Replying to myself again. :) I've found the revision that has caused this problem: http://projects.edgewall.com/trac/changeset/2990 If I roll back to 2989 the slowness goes away. We're talking about more than a tenfold difference here, not just a couple of extra seconds. I've raised a ticket so the problem can be properly managed: http://projects.edgewall.com/trac/ticket/2891 -- Russ _______________________________________________ Trac mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac
