Trac Plus Subversion -- Per Erik Strandberg

Content Management (f.x. Subversion)?

Content management is when you want to store the history of a file - f.x. source code in an intelligent way (other than calling the file report.doc, then make a backup and call it report1.doc, and then email it to some colleague that resends you another version called report1_mod.doc that you have to merge with your now updated version).

One content management system is CVS, and another is SVN (subversion). Subversion has a lot of nice features compared to CVS; f.x. a file can be renamed or moved. The revisions are in fact specific folders and not files, and so on.

A typical situation is when you want to know what happened between revision 4 and the current revision.

>svn diff -r 4 kalendar.txt
Index: kalendar.txt
===================================================================
--- kalendar.txt        (revision 4)
+++ kalendar.txt        (working copy)
@@ -1,6 +1,6 @@
  ______________________
 /      June 2007       \
-| Mo Tu We Th Fr Sa Su |
+| Må Ti On To Fr Lö Sö |
 |              1  2  3 |
 |  4  5  6  7  8  9 10 |
 | 11 12 13 14 15 16 17 |
@@ -15,8 +15,5 @@
  *     $Date$
  *     $Author$
  *     $Revision$
- *
- * TODO: 
- *
  */

Trac: three in one

Trac provides three extremely nice features:

A web interface to the subversion history.
An issue-tracker (like bugzilla).
A wiki engine.

TRAC has web interface to subversion

You can look at the history of a file and if you make commit comments that are relevant you can link from the revision history to the issue tracker with an easy syntax. In this screenshot there is a link to the first bug (or ticket as they are called in trac), also there is a link to a certain checkin (revision 5).

Also you can see the diff's made in the source-code. Here I have removed some lines and one line is changed from English to Swedish.

TRAC has an issue-tracker

The TRAC issue tracker is the core feature of TRAC and it seems to do what it should - I haven't tried it fully yet. A ticket can have an reporter and someone else that is working on it. And it can be solved.

The ticket can of course have comments and link to other tickets and specific revision and check ins.

the TRAC wiki

This is a little overkill but can be nice. If you are developing a project in the open source community it might be nice to have the a description of the source code, the bug-tracking and a description of the product (in the wiki) under the same umbrella.