Viewing very large changesets runs forever

[doug.winter@…]

We have a changeset in a git repository that is extremely large. When viewed on github, github just refuses to display it.

Trying to view the changeset in Trac causes it to spin and eat CPU for a very long time. I gave up after 10 minutes.

Trac should probably refuse to display changesets of larger than a specified size.

I am using trac 1.0.1 from ubuntu trusty.

[Ryan J Ollos]

What are your settings for [changeset] max_diff_files and max_diff_bytes?

[anonymous]

[changeset]
max_diff_bytes = 10000000
max_diff_files = 0

Which looks like the default values.

[Ryan J Ollos]

Since Trac has the feature you are requesting, the thing to do is change the settings to something more appropriate for your installation. Could you try reducing the value of max_diff_bytes in 1 MB increments and let us know what value prevents Trac from attempting to render the changeset? That will give us a good idea of the size of the changeset that is causing you trouble, and will allow you to set a more appropriate limit for your installation.

Perhaps our default value of 10e6 is too large for a typical Trac installation. The default value of 0 for number of files to display puts no limit on the number of files displayed: TracIni#changeset-section.

If your changeset contains only one file then max_diff_bytes will be ignored, see [2968]. How many files does your changeset include?

[Jun Omae]

I think that is a duplicate of #10267, not a plugin/git issue.

[anonymous]

I've turned max_diff_bytes down to 1MB - anything more than this really murders the server. At 1MB it seems to all work ok. I have left max_diff_files at 0 for now.

I didn't realise these settings were there, and it might be worth considering reducing the default.

Thanks very much for your help.

[Ryan J Ollos]

I guess we can close this as a duplicate of #10267 then. The workaround of reducing max_diff_bytes would not seem to cover every scenario.