$ git svn dcommit
6 [main] perl 4760 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap C:\cygwin\lib\perl5\site_perl\5.8\cygwin\auto\SVN\_Core\_ Core.dll to same address as parent(0x260000) != 0x990000 84 [main] perl 3224 fork: child 4760 - died waiting for dll loading, errno 11 panic: MUTEX_LOCK (45) [util.c:2331] at /usr/bin/git-svn line 787. panic: MUTEX_LOCK (45) [op.c:352].

The reason behind this behavior is a huge difference in the way processes and threads and libraries are created/handled on Windows and Linux. git-svn relies on perl within cygwin and several perl libraries that use the same base-address for libraries internally. Of course, no two libraries can be loaded to the same base-address at the same time.

Long explanation, short way to fix the problem:

1. Quit all cygwin processes
2. Start ash (<cygroot>\bin\ash.exe) (<edit>Use “Run as Administrator…”</edit>)
3. Execute /usr/bin/rebaseall

Voilla, that’s all. git-svn should work again.

What I really love about Git is the fact that it nicely integrates with existing Subversion repositories. At our company, we are using Subversion as our SCM, but I personally like Git more and I want to use it as a side tool for more flexible branching, merging, and for checking in versions I wouldn’t check in the shared repository.

Git is supplied with git-svn, which can import an existing SVN repository and also commit back to it. Under cygwin, you need to perform two additional steps for getting git-svn to work, otherwise it is likely to fail with “failed to include Error.pm”.

• subversion-perl (install via cygwin‘s setup.exe)
• Error.pm

You need to download Error.pm from CPAN. You have to save it to <cygwin-dir>\lib\perl5\Error.pm

Voila! git-svn should work now.

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.