What headaches should I expect from using Trac?

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.

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

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}

We've used Trac for several years with multiple projects. After thinking for a minute I still can't come up with any significant problem to list.

http://trac-hacks.org/ticket/131 - Persistent Logins (i.e. persistent login session cookies across browser restarts) is still not committed.

It means when you get your svn post-commit mail with the trac link then if your browser isn't already loaded (remembering your login) you have to enter your credentials to see content (depending on how you have security set). This is only an issue if you only trust a certain class of users on your network. Browsers remembering credentials mitigate this, and for high-security situations you may not want the option at all, but for us it is slightly annoying.

0.12 is quite close to release, i would go straight for r9125 trunk or thereabouts:

• multiple source repository support (branch landed in trunk with r9125)
• live text editing previews
• ticket comment editing with diffs are

those are three primaries why i went ahead and moved all my envs into 0.12dev. there are many more minor nice things that make a difference over 0.11, though.

i think running trac out of SVN working copy provides very nice upgrade and general manageability, so that is what i would recommend.

multiple project support is the biggest culprit so far and i'm looking to put in some work myself to improve that situation.

When someone else reassigns your ticket, you don't get notified.