Yes, it will. And that will be our next feature to implement. We’re planning on abstracting the source browser/commit viewer in such a way that plugins can be written to support any number of revision control systems.

We’re also looking at tight integration with commits and tickets, for example:

• Commit messages can be automatically added as a comment to a ticket
• Commit messages can be used to close a ticket

At some point in the future, I’d like to see a ticket automatically opened and assigned to a developer who breaks a build. With some other integration testing features, and commit-must-be-reviewed features, it should be a pretty strong offering.

What else should we do with the revision control system?

A simple way to create links in the wiki to a file+revision would be nice. This is the great strength of Trac - it's easy to make links from anything to anything (wiki pages, tickets & comments, and commit messages)

This will be fully supported. Right now, if you mention a ticket by using the word ticket or bug, followed by a number, like: ticket 139, it will be turned into a link automatically.

Peter, do you know the RSCM project (on rubyforge) ? It’s an SCM abstraction done in ruby. I don’t know what it’s worth it, but it might be interesting to look at.

One thing that is important for even small groups is to be able to have a small workflow and status for tickets. In our group jobs go from Open, to Assigned, to Test, to Documen, to Close. Closed in Favor Of, and Overtaken By Events can occur at any time. That type of simple tracking of process can help a group where different people fill different roles. When making a check-in it should be possible to set the status of the attached tickets to show progress of lack there of.

This is all really good stuff.

I really want to make Devalot tickets work this way, mirroring the development workflow. I welcome any other suggestions in this area. Also take a look at ticket 225. I’m trying to make it easier to see which tickets affect you.