For quite some time now, I’ve been running Trac over at software.complete.org. Most of my free software projects — well, the ones where I actually go to the effort to make formal releases — have a Trac instance. This Trac instance provides a wiki, bug tracker, downloads area, timeline (with RSS feeds), and VCS integration.
Trac is a nice program, but one thing has bugged me about it all this time:
Every trac instance is its own island.
I have 17 trac instances out there for my projects. To see what bugs are out there on my own server, I have to check 17 websites (or 17 RSS feeds or whatnot). Publishing a new program is not a lightweight process.
So today I started poking around looking for something better. I really like Trac’s way of integrating the wiki with the BTS and the commits; wiki markup can refer to a bug or a changeset, and bugs can use wiki markup too.
I looked at Redmine, Mantis, and Roundup, and I also have experience with RT.
Of these, Redmine looks the most interesting. Multiple projects support, per project wiki and forums, gantt charting even, and support for SVN, CVS, Mercurial, Bazaar, and Darcs — with Git support out there as patches to their development tree already too. Oh, and I saw references to a Trac importer as well. One thing that makes me nervous, though, is that they have no links to sites that use Redmine (except one in the news section), and Google isn’t turning up users either. Does nobody use this thing?
What else should I be looking at?
Over on the Git side, I’m still liking Git. I have now migrated several Mercurial projects over to git (see git.complete.org). I am also playing with Darcs to git migration using darcs2git, which also is going well. Sometimes gitk shows a nicer representation of a Git repo converted from Darcs than I was able to get from Darcs.
Hi John, AFAIK, trac over git repositories is really bad. I thought you were going to talk about this issue when I was post’s title.
This is keeping me from migrating fully to git.
By the way, multiple project support for trac is coming soon, anyways for planning purposes I think having a global trac is a bad idea.
I’m trying it out right now with the GitPlugin, and so far it is working quite well. I haven’t done anything too stressful on it yet though.
Yes, trac has had several proposals floating around for a long time now about multiple projects and how all that will work. Looks like things are finally shaping for a future release… see
[url]http://trac.edgewall.org/wiki/MultipleRepositorySupport[/url]
[url]http://thread.gmane.org/gmane.comp.version-control.subversion.trac.devel/3162[/url]
Well, yes I am aware of the “coming soon” noises. But as far as I can tell, it’s still vaporware.
That particular page is actually different from what I’m talking about. On that page, there is support for more than one repo per project. What I want is a way to see bugs that are set up across all projects.
http://ikiwiki.info/tips/integrated_issue_tracking_with_ikiwiki/
You might try [url=https://www.drproject.org/DrProject]DrProject[/url]. It was forked from Trac a few years ago by some folks at the University of Toronto to make it easy to manage student projects.
It’s targeted for classroom use, so some of the interfaces have been simplified, e.g. no Component, Version, CC: fields on tickets.
It only supports svn right now, but I got the TracGit plugin working without too much trouble.
I’m another happy drproject converted (from trac), and considering a Mercurial backend
Ah, those Ruby people, who seemingly never heard of Freshmeat. No wonder noone uses Redmine — potential users rarely look for general applications at rubyforge.
Besides they made very bad first impression to me by being translated (I have Accept-Language: cs, en), but failing to do it properly. They get plural forms wrong (Czech has plural=(n == 1) ? 0 : (n >= 2 && n <= 4) ? 1 : 2) and many translations simply don't fit in the context (either by gramatical form or even using wrong synonym). Ok, that's not the most important feature, right. However, it does not seem to support ticket dependencies and subtickets, which is biggest limitation of Trac we hit at dayjob. Besides for opensource projects I really hate systems that require me to register to report a bug. This is one thing that Trac handles extremely nicely.
maybe flyspray? (sample at bugs.archlinux.org)
Drupal [1] with a set of extension modules is maybe something to consider. Or not… depends, plus I’m biased because I’m currently working on Drupal’s VCS integration.
Last Summer of Code, I wrote the Version Control API [2] for Drupal, enabling multiple repositories in multiple version control systems to go together on one site. What it currently does is providing commit logs (including RSS, of course), optionally including links to the affected project (when integrated with the Project module [3], which provides the issue tracker) and links to diffs and file contents (which needs to be on an external web app, like gitweb).
Advantages:
– Drupal is like lego: you can include wiki functionality, issue tracking, download areas, forums, …whatever you can think of, and combine it to your likings. If you like things being modular instead of the fixed-predefined-functionality approach, Drupal is for you.
– The Project module and Version Control API are getting quite a bit of traction at the moment, healthy community, and stuff. And of course Drupal is one of the premier flagship web frameworks overall.
– VCS backends for Git, Mercurial, Subversion and CVS currently exist. I guess a Bazaar backend will only be a matter of time.
Disadvantages:
– Version Control API is still a bit in flux, and the Git backend is also rather new (like, a month old – a GHOP task). One or two upgrades might not go completely automatic yet.
– Some features like a repository viewer, diffs, or closing an issue automatically with commit messages are not yet implemented. Likewise, only CVS can do automated management and synchronization of your Drupal user with your VCS account currently.
– No detailed view access permission system yet, it’s all or nothing atm.
For more information on the version control related stuff that I did, you can have a look at http://groups.drupal.org/taxonomy/term/2408 – more general project management group discussions can be found at http://groups.drupal.org/issue-tracking-and-software-releases
Have a look, and see if you like it :)
[1] http://drupal.org/drupal-6.0
[2] http://drupal.org/project/versioncontrol
[3] http://drupal.org/project/project
we use this at work to integrate bug tracking with the wiki and with the commit logs. Works reasonably nice. We’ve also patched insurrection to do the same as ViewVC, so I’m sure you can apply the concepts to roll your own quite quickly.
http://oss.segetech.com/bugzilla-svn-wiki.html
I’m using redmine for my personal projects, it does the job, and it does it well.
As for sites using redmine – redmine’s own site is all on redmine, so you were using it when you were checking their site.
The mercurial integration very well done – its the DVCS I use – and makes things really easy.
You may want to try Launchpad.
Ok, you seen to have small repositories. My trac is over the full gcc git repository, and is frankly unusable, we had to disable trac’s browser.
However having a small repository does just makes the load manageable, but your apache will use lots of cpu compared to svn.
GitPlugin people are well aware of the issue, which is a design defect, but it will take a lot to be fixed.
Have you considered just incorporating all your projects into one Trac project? Then the former projects could be just components under the big umbrella project. Naturally, there could be some showstoppers that I am not aware of.
Well, that gets unwieldy for a few reasons. One is that each project has its own repo, which Trac doesn’t necessarily grok. Another is that the file downloads area would be a mess. Finally, the wiki pages could clash, etc.
Also it would not be possible to authorize someone to one project but not another.
A few days ago, I discussed Trac and Redmine. Redmine is a project management tool, similar to Trac, with built-in download tools, bug tracking, etc.
Redmine has a lot of nice features. Chief among them is better integration between multiple projects
About having to check multiple RSS feeds, why not just setup a planet that compiles them for you and then check that planet?
trac has really flexible authentication: it relies on the web server’s authentication policies.
So if you’ve configured apache reasonably, you should be able to have one login that would get you at all the different trac instances.
For interlinking between trac instances, there’s a simple InterTrac
wiki link syntax
Integration isn’t so great, its true (for example how do you pull ticket reporting pages together so you can see a list of your highest-priority tickets, regardless of project)
Lighttpd now uses Redmine.
http://redmine.lighttpd.net/
Just getting trac and git to work together has caused nightmares for my team, the development version especially. I am surprised to hear praises.
On the other hand, it will be great if you could publish the ingredients of your trac+git magic sauce. (My team also hates SVN).
Using trac, git plugin, gitosis is quite easy. The problem is it only supports one repository.
I use debian, which correctly installs gitosis
read the example.conf
but debian’s trac git plugin was broken, build your own
trac
/conf/trac.ini
[trac]
repository_dir = /srv/gitosis/repositories/genist.git
repository_type = git
[git]
cached_repository = true
shortrev_len = 7
persistent_cache = true
git_bin = /usr/bin/git
ping if you need help
I had this problem on Debian (Lenny) as well.
I also had to manually build it and added
[components]
gitplugin.* = enabled
tracext.git.* = enabled
and had to give www-data write access to the repositories.