Trac vs. Redmine [closed]

by

I would favour Trac. I’ve used Trac a long time over 7 years by now. I’ve also worked 3 years with Redmine. Latest versions I used in production were: Trac 1.0.1 and Redmine 2.2.3. But Redmine has some serious drawbacks over Trac:

  1. Installation is not easy:

    1. You cannot use Debian/Ubuntu package system for production use

      • As configuration is not separated from application code, whenever you get package updates, they will overwrite your changes.
      • Debian had 5 security holes at the beginning of 2013 (January), where some still unfixed in unstable and testing. Of course fixes in Debian stable is done, the package versions are so outdated in stable, that newer versions of Redmine will not work.
      • Redmine’s dependencies are fixed, so new library versions might not work. This is the reason that you must configure your apt-get or aptitude not to upgrade certain dependencies.

    2. I advise you to install via gem and bundler. However, this was as easy as described on the homepage. But what I hate most about those software package management systems beside the systems package-management is, that you have to care for updates and all other stuff separately. Some people suggest RVM providing virtual ruby environments, where you can have multiple Rails versions installed next to each other, which is not possible with apt-get. I don’t feel good with this but at least it works.

  2. Administration is not easy, considering making a backup: In Trac this is a one-liner, in Redmine, you have to backup: configuration, attached files and database content all separately. Additionally, often it is stated that Redmine supports multiple projects, so its easier to setup a new project and configuration is not duplicated. See below, there is an extra paragraph on multiple project support. Last but not least, whenever I administer a Trac project I love to edit PLAIN-TEXT configuration files. In Trac there is only one such file you need to look at: trac.ini.

  3. Configuration is broken: E.g consider creating custom routes in Redmine, that show the start wiki page and not the project overview as first page. You will be recommended to edit Redmine’s sources! That is very dangerous as next update will overwrite your configuration. So such kind of configuration was not really intended. But a good tool should separate configuration from application source code.

  4. Wiki features missing: Some important wiki features are missing due to an unfixed bug related to a XSS vulnerability. (e.g. see textile wiki markup). So you will end up not able to place comments inside wiki pages, render images in custom size,…

  5. Missing Spam protection: Yes there is an outdated reCaptach plugin, but it doesn’t work anymore. Especially the fork also protecting the issue-pages. Compared to Trac which has a SpamFilter plugin which has fantastic properties this is a no-go. No one wants to delete spam manually.

Many critical points have been made over time that made people say, Redmine is better. I doubt those:

  1. Multiproject support: Of course Trac provides multiple projects, each having its own configuration!, and this is very helpful: Consider making one project closed source and one open source. For the closed source you will probably hide the Repository, but not for the open source project. this is not possible with Redmine. Furthermore, with Trac you can Backup the projects separately and of course you can separate them incase one of your 50 projects become popular so it will need an own server! Redmine cannot do this. Recently, a new plugin came up supporting multiple user projects in one Trac instance, look at http://trac.edgewall.org/wiki/PluginList#MultipleProjects

    Beside that, there is a Project using Trac to build this feature: Bloodhound

  2. Version Control System: I think installing a plugin is not that hard, and for almost every VCS there is a plugin for Trac: Git, Perforce, Mercurial, Darcs, Monotone, Subversion, Bazaar. Furthermore I would favour a small core framework with plugins over a big framework with integrated support for Git, Mercurial, etc… Such an architecture is not modular. So putting VCS support to plugins is the way to do it. Not to integrate everything into the framework.

  3. Plugins: I would argue Trac and Trac-Hacks have much more plugins than Redmine, so integration of Doxygen, Jenkins, Latex, BibTex, etc. is no problem!

  4. Timing and Estimation: There are plugins for that in Trac too!
    All in all I don’t understand the recent Trac-bashing, It’s also written in a trendy interpreter language (python), it has almost the same functionality.

Redmine’s installation process is not easy, but Trac installation became also more complex these days so manual database creation, etc. can’t count as a drawback anymore.

Last but not least, both projects using a plugin system. The problem the user of such plugins often has is, they may be orphaned and not supporting the current framework. This happend to me more than a dozen times for Redmine, but also sometimes for Trac. But my very subjective impression is, that crucial plugins were never affected by this kind of problem and with Trac that happened a bit fewer.

Last Last but not least least, I will try out Phabricator as it offers builtin workflow for code review.

Leave a Comment