Trac vs. Redmine [closed]
I'm working in research and my bioinformatics work group needs a project management software for keeping track of multiple projects (Linux environment). Originally, we planned for using TRAC but then I got aware of REDMINE. Moreover, I read in some earlier posts from 2008 and 2009 that many projects had switched to Redmine. Right now, I cannot find any up-to-date or reliable comparison between both systems and thus cannot wage which one is better (maybe both are equally good).
My question:
Does anyone of you have recent experience in one or even both of these systems and can point out some (big) advantages/disadavantages of either Redmine or Trac (or even both)?
Requirements would be:
- svn and/or dcvs (Git) support
- document management
- ticketing
- bug tracking
- wiki / internal blog (i.e., knowledge management)
- multiple project support
- installation should be as easy as possible
- there shouldn't be hundreds of plugins to be installed before getting a usable project management software up and running (base installation should have most features)
Thanks a lot for your time! Cheers
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:
-
Installation is not easy:
-
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.
I advise you to install via
gem
andbundler
. 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.
-
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
.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.
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,...
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:
-
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
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.
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!
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.
I use Redmine and ... i like it ;)
- svn and git works fine, it has more repos implemented (Darcs, Mercurial, Cvs, Bazaar, Filesystem ??? ), but haven't tried using them
- about installation - in my case auto installator on my hosting, so i can't say a thing, you should be able to find many tutorials
- ticketing / bug tracking - i think, for both RM and Trac it is main functionality, so too much to write about ;) you can configure roles, link users or groups with project, specifying role for each you can specify your own issue (ticket) type, for eg. bug, new idea, issue priorities you have gantt chart (you can specify deadline for each issue), you can link every ticket with version of your project ... many, many features here
- multiple project support - you can have multiple projects linked with one ( i mean the same ) or more repos
- document management / wiki / internal blog - havent used this feature, but yes, RM has something for doc management and wiki module
- 100's of plugin ... i have none and still there are too many config options :P
At BitNami we provide free installers and VMs for Trac and Redmine. Redmine is definitely much more popular but Trac is getting more popular, in particular as 1.0 version is around the corner. Since you mentioned Git or DVCS support, you may also be interested in Gitorious or Gitlab
I'm working very much with redmine, and I love it!
-
svn and/or dcvs (Git) support
got it both. if you add the ticket number to the commit message, the commit will appear very elegant in the ticket, this is one of my favorite features as developer :)
-
document management
got it too, but just very minimalism. You can upload files to tickets and projects (seperately) but you can't search for them (i.e.)
-
ticketing, bug tracking, wiki
yes, yes and... yes :) I like the syntax of writing tickets or other text contents, kind of similar with the syntax at stackoverflow.com.
-
multiple project support
of cause you can create projects, sub-projects, sub-sub-projects.... with different access rights if necessary. You can also do this cascading with tickets.
-
installation and plugins
I have never installed a redmine instance, and I have no experience with ruby. I'm just a redmine user - but I know that it is possible to write own extensions (my company has written one for own purposes, to extend the tracking of time)
Conclusion: I will always use Redmine when I need a ticket system!
Update: Sometimes I am also using the issue integration of code hosters like bitbucket or github. Redmine is the largest solution I've used. Trello is also an alternative, which I like to use to handle customer tasks (you can create teams), when not much people are involved and the project is not that big.
Redmine has all that out of the box in a generally very good quality.
However the Installation of Redmine is a different issue. Redmine has a lot of dependencies and many of those dependencies have multiple versions which are not compatible with each other. I was unable to install the most recent redmine manually so far.
What worked fine however was the redmine package provided by Debian Squeeze. It's an older version (1.0.1-2) but has everything you need. I know that openSUSE and Ubuntu also provide redmine packages. (both version 1.1.3, they weren't able to get an recent version installed either, huh?)