What headaches should I expect from using Trac?

Question

No tool is perfect, and I'm about to start several long-term projects using Trac, and wanted a heads up of the kinds of problems I may or may not experience with it. In other words, Trac meets my needs in the short term, and I've already made the decision to use it, but I want to know what to expect down the road.

I am not looking for:

• "Use product X instead of Trac because..." answers.
• "Trac is great because..." answers.
• A comparison to any other specific system.
• "Trac doesn't support Feature X" answers. I can read the feature list too, thank you very much.

I am looking for:

• "Feature X does not behave as expected..."
• "Trac behaves oddly when..."
• "Trac doesn't fully support..."
• "Trac itself has a known bug that will likely never be fixed..."
• And especially "Trac can't handle..."
• etc

So, what Trac-induced headaches do I have to look forward to?

For future reference, this question was asked while Trac v0.11 was the latest stable release.

Answer 1

There is still no common view on how to handle multi projects. If this is not your case - the rest should work for you.

Answer 2

One issue that I have run into with a long-term Trac instance is the 'version' field. There is no distinction between the list of versions that can be assigned to a ticket, and the list of versions that can be queried for in the custom query interface. So if the version list for that field starts getting cumbersomely long, you can't really trim it without limiting what you can search for.

One of these days I'll get around to fixing that...

Trac 0.11 is rather more of a resource hog than 0.10 was; in large part due to the switch to Genshi for the templating engine. You may want to keep an eye on resources on the server, memory in particular. I expect to see some increased attention paid to performance in 0.13 or so.

Oh, and if you run into problems, #trac on freenode can be a nice resource.

_{Disclosure: I'm one of the Trac developers}