Maybe anyone in the area of Linz, Austria would be interested in a little mapping party one day? The data in this area seems to be rather sparse Anyways, I think the project or any similar project is definitely important and should be supported with all means. Anybody knows someone at a Austrian government body which could contribute data to such a project?

I got so enthusiastic about it that I am currently writing anything down inside it, organizing my contact data, appointments, schedules, etc. Together with this great Getting-Things-Done extension, I am really, really happy that I finally found a way to organize my thoughts, ideas, and TODOs. It all is becoming to make more and more sense now

I am so addicted to the system that I installed the whole application inside my shared data environment. I am using the old style file format, where every page is stored as a .wiki file, which makes synchronization using Unison very fast and easy, and additionally allowing (limited) conflict handling.

While still being a Python application, wikidPad was written for Windows and got Linux support added later during development, after wikidPad itself became OpenSource. At the moment, I find the Linux version being too buggy for my everyday use, so I use wine to run wikidPad there.

All types of content can easily be interlinked, as all parts interprete the common wiki link-style. For instance, “#123″ will be converted to a link to trouble ticket #123, and “r123″ or “[123]” will be converted to a link to the changeset (revision) 123 of the version control system. The same syntax is also interpreted for each commit entry or within the description of tickets, which provides a fast means of navigating to related ressources.

All information is displayed clearly in a timeline view. Changesets provide powerful and clear diff-views to show what has really been changed and the repository can be browsed for any given revision number. Any changeset can be downloaded as ZIP file, as unified diff or as individual files.

The trouble ticket system is not as powerful as Bugzilla‘s as it provides no distinction for multiple projects, but it is used more fluently and provides everything needed for a single project (regardless of size of the project).

A milestone view allows clear and easy planning of various releases and milestones and provides powerful progress measuring features.

We are currently using Trac for project management of our project. We had an existing Bugzilla database that had to be converted to Trac before we could use the tool. I used the script bugzilla2trac.py (rev. 3544, but check if there is a newer version). Our Bugzilla version was 2.20, the script officially only supports upto 2.19. Still, only one minor change was needed to get the import working with the 2.20 database scheme. At line 405, change the line to read

mysql_cur.execute("SELECT * FROM attachments a INNER JOIN attach_data ad ON ad.id=a.attach_id WHERE bug_id = %s" % bugid)

The import worked flawless, everything including attachments was imported, and (most importantly for being in-sync with our SVN commit-messages), the bug numbers where kept identical.

Trac at the moment only supports Subversion as version control system; they are working on integrating other VCs as well. Trac needs local access to the repository, as they access the repository directly, not via HTTP. It might however be possible to use a remote repository which is mounted locally using one of the many remote-fs available.

Trac natively uses SQLite as database backend for storing its data, official release also contains support for PostgreSQL and the current development version also works with MySQL. I am using the SQLite backend which caused litte problems:

Trac is written in Python, so for optimal performance it is best to use it with mod_python if you are using Apache. Be aware however, that if you also have mod_php (PHP 5) installed and mod_php/PHP is compiled with SQLite support, mod_python will not be able to read SQLite databases. A recompile of PHP without SQLite support solved the issue for me.

One last word about administration of Trac. Trac provides a powerful command-line util called trac-admin which gives you access to various settings. You use this tool for adding permissions to users, setting up components and managing severities for tickets. Most importantly, this tool also provides a means for backing up Trac: “trac-admin <repository> hotcopy <bak-dir>” will copy the current Trac environment to the backup location, while ensuring database transaction integrity.

One thing I want to mention here too is the fact that one installation of Trac can be used for several independent projects. For each project, a “Trac environment” is set up using trac-admin. The databases of the individual environments are independent, but they share the same codebase, so updating Trac updates it for every existing environment.

Concluding I want to say that Trac is definitely worth a try, you can even quick-test it by using its own webserver, so you do not have to set up Apache for use with Trac. This is however not recommended for production use.

Using Trac, project management, milestone planning, issue tracking, and documentation become fun.

The most interesting part in this posting is that if you are using a Windows 2003 Server, you need to patch the LDAP.php in the PEAR authentication module, as Win2k3 by default does not allow any anonymous queries against the directory.

In <tikiroot>/lib/pear/Auth/Container/LDAP.php search for the following line in function _connect():

if ((@ldap_bind($this->conn_id)) == false) {

and replace it with

if ((@ldap_bind($this->conn_id,"someuser","somepassword")) == false) {

Note, that someuser is in the form of user@domain.tld.

I also recommend to choose to authenticate your admin user against the internal database and not the LDAP (AD) container, otherwise you will lock yourself out easily.