[components]
gitplugin.* = enabled
tracext.git.* = enabled

and had to give www-data write access to the repositories.

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

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).

http://redmine.lighttpd.net/

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)

Redmine has a lot of nice features. Chief among them is better integration between multiple projects

Also it would not be possible to authorize someone to one project but not another.

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.

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.

http://oss.segetech.com/bugzilla-svn-wiki.html

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.

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

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.

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.

[url]http://trac.edgewall.org/wiki/MultipleRepositorySupport[/url]

[url]http://thread.gmane.org/gmane.comp.version-control.subversion.trac.devel/3162[/url]

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.