Trac is a popular open source issues management system written in Python. It also features a wiki and subversion browser. There are also countless plugins that have been created for it some of which I’m surprised aren’t included in the base install.

I’m installing this on a Ubuntu server, so you may need to find installation instructions to suit your distribution! To install the packages:

apt-get install trac libapache2-mod-python

Now to setup our first Trac project:

mkdir /var/trac
trac-admin /var/trac/example initenv

The last command will step you through some questions:

Project name - Being creative I named mine “Example“.
Database connection string - I hit enter using the default.
Repository type - I hit enter using the default as mine is SVN.
Path to repository - My repository for this example was /var/svn/example.

Next you’ll need to make sure your web server can access the files:

chown -R www-data /var/trac/

There are two ways of serving Trac through your web server one using CGI the other using the mod_python which I’ll be using. Include the following in your apache config:

 <Location /trac>
     SetHandler mod_python
     PythonHandler trac.web.modpython_frontend
     PythonOption TracEnvParentDir /var/trac
     PythonOption TracUriRoot /trac
 </Location>

This doesn’t include any security as you’ll see in most install tutorials. This is because I plan on installing a plugin to make use of a web based form log in instead.

If you restart apache then open http://ip-address/trac/ in your web browser you should see you list of Trac projects. Log in won’t work yet so we’ll continue…

Installing some Trac plugins

Now we’ll install some plugins you really can’t live without! We’ll start with WebAdmin which an interface for trac-admin command line utility. This would normally be used for adding component names to your projects - something you really should have to drop to a shell for! I’ll also install the AccountManagerPlugin while I’m at it…

First we need to configure the server to be able to install python eggs! This is how all of the Trac plugins are packaged…

apt-get install python-dev
cd /tmp
wget http://peak.telecommunity.com/dist/ez_setup.py
python ez_setup.py

Now that thats done lets get the plugins installed! Please note you may need to refer to the plugin websites to ensure you’re using the correct repository for your version of Trac.

easy_install http://svn.edgewall.com/repos/trac/sandbox/webadmin/
easy_install http://trac-hacks.org/svn/accountmanagerplugin/0.10

Now that these are installed we need to configure our Trac project to make use of them!

Open the trac.ini file inside under the /conf/ directory of your Trac project. Mine is located at /var/trac/example/conf/trac.ini

[components]
trac.web.auth.loginmodule = disabled
webadmin.* = enabled
acct_mgr.* = enabled
acct_mgr.web_ui.RegistrationModule = disabled
 
[account-manager]
password_format = htpasswd
password_store = HtPasswdStore
password_file = /var/trac/trac.htpasswd

We should setup that password file and create our first account:

htpasswd -c /var/trac/trac.htpasswd admin
trac-admin /var/trac/example permission add admin TRAC_ADMIN

Some plugins also use caching if you don’t follow this next step you’ll run in to some nasty errors (Permission denied: ‘/root/.python-eggs’) ! This is because the web server can’t write to the location they use by default… So:

mkdir /tmp/trac-cache
chown www-data /tmp/trac-cache/

Then include this line in your apache config along with the others for the /trac directory.

SetEnv PYTHON_EGG_CACHE /tmp/trac-cache

Then restart apache and cross your fingers!

Update!

After my success with this install I started looking at Trac-Hacks through all of the other plugins and also decided to install the following (I’ll update this as I find others):

• CustomFieldAdminPlugin

WebSVN is a PHP based web interface to your Subversion repositories. Its official description is:

WebSVN offers a view onto your subversion repositories that’s been designed to reflect the Subversion methodology. You can view the log of any file or directory and see a list of all the files changed, added or deleted in any given revision. You can also view the differences between 2 versions of a file so as to see exactly what was changed in a particular revision.

You can also use custom templates with it! While the standard on is functional, I’ve chosen to setup the Calm Theme for WebSVN. As you see below its far more than just functional… beautiful even…

WebSVN installation

I’m using Ubuntu as my server but hopefully your distribution has WebSVN available in their repositories as well. You may just have to look for instructions more suited to your distribution! To install:

apt-get install websvn

As apart of this installation you’ll be asked to configure WebSVN (screens below).

For these three screens:

1. You need to select your web server for configuration.
2. You can specific the parent path of your subversion repositories. If you don’t want them all available leave this blank.
3. You can specific the individual repositories separated by a comma instead of specifying the parent folder. Otherwise leave this blank.

I’m using Apache 2 and I decided to make my repositories all available so I entered /var/svn on the first screen (the default folder for most people is /var/lib/svn). This can be modified later in /etc/websvn/svn_deb_conf.inc.

The rest of the installation was simple for me! By default the WebSVN places the application in /var/www/websvn/ and Apache is already serving /var/www/ for me.

All I did was add the same authentication as my /svn/ directory by adding the following in to the apache config.

<Location /websvn>
   AuthType Basic
   AuthName "Subversion Repository"
   AuthUserFile /etc/apache2/dav_svn.passwd
   Require valid-user
</Location>

Calm theme setup

Use wget to download then gunzip and tar to explode the files. You can get the theme from the Calm Theme for WebSVN web page. Then copy the template in to the WebSVN directory:

mv calm-theme-for-websvn/ /var/www/websvn/templates/calm-theme-for-websvn

Then to setup the location of the template you want WebSVN to use. Open /etc/websvn/config.inc changing:

$config->setTemplatePath("$locwebsvnreal/templates/Standard/");

to

$config->setTemplatePath("$locwebsvnreal/template/calm-theme-for-websvn/");

Version control (also known as Revision control or Source control) is the management of different versions of files. I don’t know how large development teams could survive without it! Typically they all have one thing in common they help multiple developers contribute to a single project using an central server.

But how can it help? Have you ever worked on a project with someone else and had your files overwrite your files? Or constantly had pop your head over the fence to say “I’m going to work on file abc.xyz, okay?“. Preventing this is the selling point for me!

Version control systems can achieve this in either of the following ways:

• Locking - The simplest style is locking a file so only one person can modify it at a time. A file is checked out by one person then later checked back in.
• Merging - The more productive method merges multiple versions together. This way two people can work on the one file at the same time merging their changes when finished.

I’m going to concentrate on merging although locking is not without it’s benefits. Regardless of your system you should be familiar with some techniques used. This includes the conventional directory structure:

/branches/
/tags/
/trunk/

Or if you choose to have multiple projects in the one version control project:

/project-1/branches/
/project-1/tags/
/project-1/trunk/
/project-2/branches/
/project-2/tags/
/project-2/trunk/

Each of these top level directories has a specific purpose:

• Trunk - Where you’ll find the main line of development. Which is basically the primary repository for your code!
• Branches - Can contain multiple branches, each once a copy of the trunk that has branched off into a separate line of development.
• Tags - Contains tagged (as in with a friendly name) copies of the trunk from a specific point in time. Primarily used for taking snap shots of your released versions.

Branches can be used in two ways in my opinion:

• a unique development line never intended to be merged with the trunk - an example being one client has unique needs not beneficial to others.
• a development line which is intended to be merged with the trunk, but requires significant work which might have caused disruptions to progress on the trunk.

Where and how you work depends on your project, development team and what you’re working on!! A branch could be used for each developer working on a separate component not yet ready to be placed in the trunk. Alternatively smaller teams maybe comfortable all working in the trunk directly.

The sequence diagram below shows how a user might create a branch of the trunk and continue to work on it until merging it back in to the trunk.

A good practice shown above, is to merge the trunk into the branch periodically. This makes the process of finally merging the branch into the trunk more manageable! Additionally you should do this again immediately before merging your branch into the main line of development once it’s complete…

There are a number of different systems, my preferred is Subversion (SVN) , another common one is Concurrent Versions System (CVS)… Here are some websites that helped me get my head around this:

• The Top Ten Subversion Tips for CVS Users
• Version Control with Subversion - Branching and Merging
• Revision control - Wikipedia

I’m reasonably new to this so… Please let me know if you’re aware of any corrections required to the above!