I've used trac+svn on my last job as well as on my current job. I gotta say I find the setup to be awesome! The way you can cross-reference tickets (in trac) and revisions (in svn) is very compelling. When being close to deployment I like to tie every commit very tightly to a ticket, making it easy to keep track of the changes even on larger dev teams.
Setting it up on debian should be easy using apt-get install.
An alternative to trac is Mantis. I haven't used Mantis nearly as much as I've used Trac, but I certainly didn't like it as much.
EDIT: To setup svn/trac references you need to do two things as far as I remember:
- Setup a post-commit hook on your svn repository.
- Edit you trac.ini.
I think this is quite well explained here, event though the text could be clearer.
This is from my setup:
Setting up a post-commit hook on your svn repository.
The following is from my /path/to/svn/repos/myrepo/hooks/post-commit :
REPOS="$1"
REV="$2"
TRAC_ENV="/path/to/trac/"
/usr/bin/python /usr/share/doc/packages/trac/contrib/trac-post-commit-hook -p "$TRAC_ENV" -r "$REV"
Edit you trac.ini.
This is what I have added to my ini file, I don't remember the details around them, so you'll need to look that up yourself:
[trac]
....
repository_dir = /path/to/svn/repos/myrepo/
repository_type = svn
...
[svn]
branches = trunk,branches/*
tags = tags/*
[components]
trac.versioncontrol.svn_fs.subversionconnector = enabled
EDIT 2: What I am referring to with "keeping it tight" is actually not enforced by svn nor trac, its just a mindset that I think work very well, at least in my group. We use trac from the beginning to end of each development cycle, and we put all requested features/bug fixes/enhancement into tickets. As soon a feature has been developed the developer puts the ticket up for testing, and when the testing has been approved (by PL) the ticket is closed. During the normal cycle, however, sometimes developers commits things that are not related to any ticket, it could be a small feature or a bug fix that no-one knew about, and here you get two choices: either you let it go (fast, simple) or you create a new ticket to tie the commit to (slow, cumbersome). We usually go by the quick fix here unless it is a major new feature.
Towards the end of the cycle, however, it gets more and more important to keep track of each commit, as every commit potentially could break the system. Thus I find it very useful to force (by the spoken word) each developer to in each commit write what ticket id the commit is related to. (If you in the comment write #123 as you commit to svn where 123 is the ticket number you can actually browse this in the trac time line, awesome!)
This has two effects: 1) The developers take one extra look before they commit, so that everything in each commit is only related to the specific ticket. 2) It gets easier for me to see what features/bug fixes that I can test per commit. I could for example checkout revision 123 to test one bug fix and 124 to test another, if I would like to test them one at a time.
Well, this starts to become an small essay and I need to stop here. I hope that you understand what I mean. I guess my advice would be to setup your own guidelines that are well-known within the development group, and make use of #123 (ref to ticket) and r234 (ref to svn revision) as you write commit-comments and new tickets.
(I.e., when you reply to a ticket you write "I fixed XYZ in r345.", then r345 will become a link to the svn tree and you can see exactly what was changed in this revision.