Trac and Subversion

Trac has supported the ​Subversion VersioningSystemBackend since day one. Actually, Trac was even named svntrac back then!

This page is intended to collect all the specific tips and tricks about Subversion support in Trac. This is not the place for general Subversion help. You can get more support options elsewhere.

At the time of this writing, the preferred Subversion version for Trac is still 1.2.3. If you are willing to make a few changes to the stock 1.3.0, that version works also pretty well.

Building Subversion

The point is not to repeat the excellent build instructions found elsewhere, but rather to clarify the general approach: Trac actually needs the SWIG bindings for Subversion that are bundled with the Subversion distribution. In order to build them, you (obviously) need to build first Subversion, then the bindings.

• Read the INSTALL file that sits at toplevel of the Subversion source distribution
• Do ./configure ...; make; make install
• Read ./subversion/bindings/swig/INSTALL in order to build the bindings. In particular, pay attention to the version of SWIG which can be required (1.3.0 comes with pregenerated wrappers, though). Do not install swig 1.3.28 or 1.3.29. Version 1.3.27 seems to works fine.
• Do make swig-py; make install-swig-py
• Adapt your PYTHONPATH so that it contains the svn-python folder (the one containing the svn and libsvn packages). If you're using TracModPython, be sure that Apache will also see this environment variable, or alternatively use the PythonPath mod_python directive.

Trac and specific Subversion versions

Trac and Subversion 1.0

This is the oldest supported Subversion version.

Trac and Subversion 1.1

This release introduced the fsfs repository backend, which is to be preferred over the bdb one (see #571 for example). When creating a repository with this Subversion version, take care of using the --fs-type fsfs switch with the svnadmin create command. Version 1.1.4 is the last stable one for that maintenance branch.

Trac and Subversion 1.2

This release makes the fsfs storage the default. Version 1.2.3 is the last stable one for that maintenance branch.

If you switched from a previous version to this one, chances are that you had a Berkeley DB repository. It would be a good idea to switch that repository to the FSFS backend. ​google:svn+convert+bdb+to+fsfs.

Trac and Subversion 1.3

This is the newest major release for Subversion, and it is currently support by Trac 0.9.x and beyond, with a few caveats.

Trac and Subversion 1.3.0

There are a few known issues with the stock 1.3.0 version:

• Issue #2472 (spurious exception)
  which can be fixed by applying this patch to subversion/bindings/swig/python/svn/core.py
  Should be fixed in Subversion 1.3.1 (r17992).
• Issue #2620 (memory leak)
  which can be fixed by applying this patch to subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c.
  Should be fixed in Subversion 1.3.1 (r18230).

With those fixes, I've been able to use the Subversion backend flawlessly "in production", since end of January 2006.

However, some people are seeing yet another problem, which requires one more fix:

• Issue #2611 (intermittent fatal error)
  which was supposedly fixed by applying this patch​ to subversion/bindings/swig/include/proxy_apr.swg. Note that this requires to regenerate the SWIG bindings, as explained in here. It should be emphasized that a compatible version of SWIG must be used (1.3.24, 1.3.25).
  Should be fixed in Subversion 1.3.1 (as the above patch was integrated as r18721)

Trac and Subversion 1.3.1

As mentioned above, the issues found with 1.3.0 should be fixed by 1.3.1. However, I've not yet tried 1.3.1. so I can't tell for sure that there won't be any issues…

Note: Issue #2611 was confirmed to still exists in Subversion 1.3.1 and also in the stock 1.3.2, when compiled using the pre-generated bindings that were produced using SWIG 1.3.25
So it seems the patch discussed above was not enough to solve the problem. Also, the issue is most certainly related to the use of multiple python sub-interpreters, either because those are created by default when different virtual hosts are used (#2965, #3455) or because different "PythonInterpreter" directives are used in different <Location> sections (#2713).

Asking for More Support About Subversion

• ReadTheFineBook: ​http://svnbook.red-bean.com and/or the ​FAQ
• There's also a #svn channel on the freenode IRC network
• If you think you've found a bug in Subversion, read these ​instructions