Today while I was setting up a Subversion 1.5 installation over Apache 2.2.10 on Windows, I was experiencing a strange difficulty. After making the necessary configuration details on httpd.conf and I tried running the server, everything went smoothly, however when I made it run as a service, it would not run and give the following error:

“Cannot load C:/../modules/mod_dav_svn.so into server: The specified module could not be found.”

Even though this module was at the right location. After googling for a while and reading the Subversion FAQ for this problem and another useful document, I tried all the suggestions but the problem would still persist. After a while of tinkering, I resolved it by copying the following libraries from the Subversion’s installation to the modules folder of Apache:

• intl3_svn.dll
• libdb44.dll
• libeay32.dll
• libsvn_client-1.dll
• libsvn_delta-1.dll
• libsvn_diff-1.dll
• libsvn_fs-1.dll
• libsvn_ra-1.dll
• libsvn_repos-1.dll
• libsvn_subr-1.dll
• libsvn_wc-1.dll
• ssleay32.dll

I hope this post helps those who are having problems with Subversion deployments.

It did not use to be like this in previous Subversion releases, usually after putting the *.so files on the modules entry on Apache and configuring httpd.conf it was enough to make it run…

What’s Continuous Integration?

As Martin Fowler said, Continuous Integration is a software development practice where several people integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day.

One specific point of Continuous Integration is that the verification of the integration is done automatically using what is called a Continuous Integration Server. This server will fetch the latest code from the corresponding VCS in use (hopefully Subversion, read my article about it).

Why Continuous Integration?

The most important advantage of following the Continuous Integration practices is that errors are detected in a much earlier phase, specially when you use it along with Test Driven Development. Errors in this context not only mean bugs but integration errors as well, as integration is done on a daily basis.

It is not the only advantage of course, for example, deployments to production are a LOT easier as the build process is already in place. I recommend reading the benefits section of Fowler’s article for a detailed explanation.

Tools and Useful Resources

I have used the following tools for doing Continuous Integration:

• CruiseControl
• CruiseControl.NET

I also heard good things about Hudson, so give it a try as well.

Useful resources:

Martin Fowler on Continuous Integration

6 Steps to Successful Continuous Integration

Enjoy!