I have previously reported on some problems I had when upgrading our Trac install at work. Today I attempted another upgrade to Subversion 1.7.4 and Trac 0.12.3 on Windows. I upgraded to Python 2.7.2 along the way. I ran into another problem with the Python bindings to Subversion which took a while to figure out. I had no problems upgrading Subversion, but Trac could not see our repository. The symptoms were that the Trac "timeline" and "browse source" features were missing.

Following the Trac troubleshooting advice, I opened an interactive Python session and tried this:

E:\Trac_Data>python
Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> from svn import client
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "C:\Python27\lib\site-packages\svn\client.py", line 26, in <module>
   from libsvn.client import *
 File "C:\Python27\lib\site-packages\libsvn\client.py", line 25, in <module>
   _client = swig_import_helper()
 File "C:\Python27\lib\site-packages\libsvn\client.py", line 21, in swig_import
_helper
   _mod = imp.load_module('_client', fp, pathname, description)
ImportError: DLL load failed: The operating system cannot run %1

After some head scratching and googling I finally found the problem. I had used the Windows .msi installer, graciously provided by Alagazam, aka David Darj, to install Subversion. This placed the Subversion binaries and DLL's in C:\Program Files\Subversion\bin. I then unzipped the Python 2.7 bindings to the C:\Python27\Lib\site-packages folder. The bindings depend on the DLL's in the Subversion\bin folder. But unfortunately for me, there were already two older versions of the DLL's, libeay32.dll and ssleay32.dll on my path. So when the bindings went looking for those two DLL's, instead of finding them in Subversion\bin, it found the older versions somewhere else.

To fix this, you can either rearrange your path, or copy those two DLL's to your Python27\Lib\site-packages\libsvn folder. In the future, I am going to just copy all the DLL's from Subversion\bin to the libsvn folder.

I examined the pre-built Subversion packages from Bitnami and CollabNet. They had packaged all of the Subversion DLL's with the Python bindings together in the same directory, so this seems reasonable. Later, on the Subversion users' mailing list, Alagazam gave the nod to this approach.

A big thank you to Alagazam for the help and for the Windows binaries. And of course thanks to the Apache, Subversion, Trac, & Python teams for making great tools.

At work, we are outfitted with Windows servers. Despite this obstacle, I managed to install Trac and Subversion a few years ago. During a break in the action, we decided to update Subversion (SVN) and Trac. Since we are on Windows, this means we have to rely on the kindness of strangers for Subversion binaries. I ran into a couple of gotchas I'd like to document here to help anyone else who runs into these.

I managed to get Subversion and Trac up and running without any real problems. However when Trac needed to access SVN to display changesets or a timeline, for example, I got an error:

tracerror: unsupported version control system "svn" no module named _fs

After some googling, I finally found that this issue is documented on the Trac wiki, but it was kind of hard to find. To fix this problem, you have to rename the Python SVN binding's DLLs to *.pyd. Specifically, change the libsvn/*.dll files to libsvn/*.pyd, but don't change the name of libsvn_swig_py-1.dll. I'd really like to hear an explanation of why one needs to do this. Why doesn't the Python-Windows build process do this for you?

The second problem I ran into dealt with mod_wsgi on Windows. Originally, a few years ago, I setup Trac to run under mod_python. mod_python has long been out of favor, so I decided to cut over to mod_wsgi. On my Linux boxes, I always run mod_wsgi in daemon mode. When I tried to configure this on Windows, Apache complained about an unknown directive WSGIDaemonProcess. It turns out that this mode is not supported on Windows. You'll have to use the embedded mode on Windows.