I use a combination of Trac and Subversion to manage my software development projects. Although new projects like lighthouse and git have cropped up which look very intriguing, the lack of automated installation and maintaince and my lack of free time leaves my turning back to my existing trac + svn solution. The integration between these two projects is simply spectacular and the ability to have the software hosted and easily managed on a low cost shared server like DreamHost is definitely a plus.
There was one missing piece after the initial installation process of svn + trac: post commit trac integration. Automatic integration of ticket updates and source code commits usually runs without a problem, but since svn runs under a different user than trac, permission issues arise. The easy solution would be to increase permissions on the trac database file, but this isn’t a very secure solution. The best solution that I have found is to create a proxy file, which holds basic commit information (revision numbers and commit messages), to act as a middleman between trac and svn and then schedule a cron script to pull the logged data and run it through the trac post commit script. Information on how to do this was scattered around the web so I took the time to pull it all together and organize it into one post.
File: ~/trac_projects/project_name/run-post-commit-proxy.bash
Note that this file needs to be run by the same user which handles svn commits (on DreamHost just run this script every five minutes as the user which hosts your svn).
#!/bin/bash
LD_LIBRARY_PATH="/home/user/packages/lib"
PATH="/home/user/packages/bin:$PATH"
PYTHONPATH="/home/user/packages/lib/python2.4/site-packages"
export PYTHONPATH
export PATH
export LD_LIBRARY_PATH
/home/user/trac_projects/project_name/run-queued-trac-post-commits.rb
File: ~/trac_projects/project_name/run-queued-trac-post-commits.rb
#!/usr/bin/ruby
tracDir = '/home/user/trac_projects/project_name'
logFilePath = tracDir + '/queued_commits.txt'
doneFilePath = tracDir + '/queued_post_commits_done.txt'
errorFilePath = tracDir + '/queued_post_commits_errors.txt'
postCommitScriptPath = '/home/user/packages/share/trac/contrib/trac-post-commit-hook'
tracURL = 'http://trac.domain.com/project_name/'
errorEmailTo = 'info@domain.com'
queuedCommits = Array.new
begin
File.open(logFilePath, "r") do |file|
file.each_line do |line|
queuedCommits < < line
end
end
rescue
# no queued commits to process
exit
end
# Empty out the file
system("> #{logFilePath}")
queuedCommits.each do |line|
line.chomp!
repo,rev = line.split(':')
next unless repo and rev
logMessage = `/usr/bin/svnlook log -r #{rev} #{repo}`
author = `/usr/bin/svnlook author -r #{rev} #{repo}`
# to make sure python can fine the trac module
exportCmd = 'export PYTHONPATH="$HOME/packages/lib/python2.4/site-packages/:$PYTHONPATH"'
postCommitCmd = %{/home/user/packages/bin/python #{postCommitScriptPath} -p "#{tracDir}" -r "#{rev}" -u "#{author}" -m "#{logMessage}" -s "#{tracURL}"}
if system("#{exportCmd}; #{postCommitCmd}")
# log the success
File.open(doneFilePath, "a") do |file|
file.puts("#{Time.now}:#{repo}:#{rev}:#{author}:#{logMessage}")
end
else
# write an error
errorCode = $?
File.open(errorFilePath, "a") do |file|
file.puts("#{Time.now}:#{errorCode}:#{repo}:#{rev}:#{author}:#{logMessage}")
end
# and put the commit info back in the queue file
File.open(logFilePath, "a") do |file|
file.puts line
end
# send an email
system("echo #{errorFilePath} | mail -s 'Post Commit Errors' #{errorEmailTo}")
end
end
File: ~/svn/project_name/hooks/post-commit
#!/bin/sh
REPOS="$1"
REV="$2"
# Just append this info to the log file
echo "$REPOS:$REV" && /home/user/trac_projects/project_name/queued_commits.txt
Some resources I used in putting together the above information:
I stumbled upon an intriguing alternative to Trac: Warehouse. As nice as Trac is, I was never 100% thrilled with its user interface and user management functionality. Warehouse looks to have a beautiful user interface and its user management functionality seems great. It is much closer to a GitHub like interface than most other project management systems I’ve seen lately.
Although svn is a great system, git seems eliminate any frustration still lingering in the svn workflow. Unfortunately I have many build scripts that are built around my svn repositories to it is going to be awhile before I can fully make the transition. However, it seems to be fairly simply to get git up and running on a shared server systemMatt Gemmel posted a nice review of Linode; $20/month for 356MB of ram and 16 HD space doesn’t seem bad at all.
