Trac and Subversion
Trac has supported the Subversion VersionControlSystem since day one. Actually, Trac was even named svntrac
back then!
However, things change and other version control systems gain in popularity… in Trac 1.0 we also support Git as an optional component below tracopt.versioncontrol.git.*
. As to not make any first class, second class distinction, we also decided to move the subversion support over there, in tracopt.versioncontrol.svn.*
.
In Trac 1.0 (trunk, starting from r11082), the components for Subversion support have been moved below tracopt.
so you need to explicitly enable them in your TracIni#components-section:
[components] tracopt.versioncontrol.svn.* = enabled
This can instead be enabled using the Admin → General → Plugins (Manage Plugins) select component the checkbox(es).
Note: For Trac < 1.2, the value must be enabled
or on
. Using a value of true
or yes
will not work for the [components]
section, whereas true
and yes
are acceptable in other sections of trac.ini. The inconsistency was fixed in Trac 1.2.
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.
Getting Subversion
From subversion.apache.org:
Debian Linux, Ubuntu
Install the Subversion Bindings using apt
:
Debian 11 / Ubuntu 22.04 and later
$ apt-get install python3-subversion
Debian 10 / Ubuntu 20.04 and early
$ apt-get install python-subversion
RHEL/Fedora/CentOS Linux
Install the Subversion bindings using dnf
or yum
:
RHEL 8 / CentOS 8 / Fedora 32 and later
$ sudo dnf install python3-subversion
RHEL 7 / CentOS 7 / Fedora 18 - 31
$ sudo yum install subversion subversion-python
- RHEL: While
subversion-python
package is available through optional channel for7Server
, for whatever reason(s) it's not the case for7Server
, however package is available throughrhel-7-workstation-optional-rpms
. - CentOS: package available in base repository
- Fedora: package available in fedora repository
You MUST have exactly the same version of subversion
and subversion-python
installed, otherwise the bindings won't work:
$ yum list subversion subversion-python Available Packages subversion.x86_64 1.7.14-6.el7 base subversion-python.x86_64 1.7.14-6.el7 base
RHEL/CentOS 5, 6
$ sudo yum install subversion
Windows (x64)
There are fewer providers of the 64-bit Subversion bindings for Windows than for the 32-bit ones, but those provided by VisualSVN work just fine.
All of the bindings are precompiled as 64 bit DLLs (and PYDs) in Visual SVN Server 64-bits 3.5 for W2012. No problem to work together with Python 2.7.10 64 bit.
Windows (x86)
for Python 2.7
For Subversion 1.7.x there are bindings available from http://alagazam.net.
An alternative is to use the Subversion 1.7.0 bindings from CollabNet server edition: CollabNet Subversion Edge 2.1.0 (for Windows 32 or 64 bit).
You'll find there a full Python 2.7.1 installation (below the Python25
top-level folder!) and the corresponding bindings below lib/svn-python
. It seems that even though that Python installation was built with VisualStudio 2010 (msvcr100.dll
), you can also use those svn bindings with the Python from python.org which was built with VisualStudio 2008 (msvcr90.dll
). I'm a bit disappointed, where's the DLL hell gone?
For the 1.6.x bindings, there's no "official" release to be found for Python 2.7, but thanks to dawuid, who contributed svn-win32-1.6.15_py_2.7.zip (md5 9dba3d11c4bbb91e29deb28f569e821b
). I tested them, and they seem to work great. Simply unzip in your <python27install>\Lib\site-packages folder. Note that you must have the folder containing the matching Subversion libraries in your PATH (e.g. "C:\Program Files (x86)\Subversion\bin").
for Python 2.6
Get them from http://alagazam.net: you'll need the Windows installer Setup-Subversion-1.x.y.msi
(or the Windows binaries svn-win32-1.x.y.zip
) and the Python 2.6 bindings svn-win32-1.x.y_py.zip
.
The Alagazam installer updates the PATH automatically to point to the new binary directory.
The python-bindings zip file has a folder structure of
svn-win32-<ver> python libsvn svn
The libsvn
and svn
folders should be extracted into the Python26\Lib\site-packages
directory.
For Subversion 1.6 bindings then rename the binding DLLs: change libsvn/_*.dll
to libsvn/_*.pyd
(don't change the name of libsvn_swig_py-1.dll
), the 1.7.x bindings already have the correct names.
- Note: if CollabNet is providing SWIG bindings for Python 2.6, I can't find them.
- Also note: the Subversion directory structure of the Alagazam distro is slightly different than the CollabNet one: all the executables are in the
bin
subdirectory.
If you end up with the infamous ImportError: DLL load failed: ...
, don't despair but have a look at the Windows troubleshooting section below.
for Python 2.5
One easy way to get Python 2.5 bindings is to install Collabnet Subversion Edge http://www.open.collab.net/go/csvne2_r2a/. The bindings can be found in the <install_directory>\csvn\lib\svn-python directory.
for ActivePython 2.5
One way to get the bindings is to install the CollabNet Subversion Server.
While installing ("Apache Configuration" page / "mod_dav_svn Configuration") you have to select the "Enable viewVC" option. The installer then goes to the "ViewVC Configuration" page and asks for the location of the "Active Python Directory".
Be sure to prepend the directory containing the Subversion libraries, from the server install (e.g. C:\Program Files (x86)\CollabNet\Subversion Server
) to the PATH
, or the bindings won't load.
BSDs
On the various BSDs use ports or pkgsrc to install Subversion complete with Python bindings. For FreeBSD see use /usr/ports/devel/py-subversion
. For pkgsrc use the devel/py*-subversion
package for getting the bindings.
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 top level of the Subversion source distribution - Do
./configure ...; make; make install
; if you intend to use Subversion together with Apache, be sure to configure Subversion so that it will use a compatible version ofapr
andapr-utils
, ideally those of Apache. If not, you'll be able to build Subversion and the bindings, but you most certainly have issues later on, when using mod_python (e.g. #2920). - 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 pre-generated wrappers, though). Do not install swig 1.3.28 or 1.3.29. Version 1.3.27 seems to works fine (Although not in all cases. The subversion users mailing lists suggest going back to 1.3.25, which may be necessary). - In your subversion source root, do
make swig-py; make install-swig-py
(NOTE: there is a dash between 'install' and 'swig'!) - Adapt your
PYTHONPATH
so that it contains thesvn-python
folder (the one containing thesvn
andlibsvn
packages).
e.g. if svn is installed in/opt/subversion-1.4.4
:If you're using TracModPython, be sure that Apache will also see this environment variable, or alternatively use the PythonPath mod_python directive.$ export PYTHONPATH=$PYTHONPATH:/opt/subversion-1.4.4/lib/svn-python
You may also just copy the libsvn/ and svn/ directories in the resulting installation directories, e.g. /usr/local/lib/svn-python/, to the site-packages/ directory in your /usr/lib/python2.x/ directory. Python will then find them without having to adapt yourPYTHONPATH
.
Getting Subversion working
(this is a cite from TracOnDebianSarge as this is extremely useful for first time user setting up subversion repository)
To create a Subversion project at /var/svn/project, issue these commands to get SVN up and running:
$ mkdir -p /var/svn/project $ mkdir -p /tmp/project/{branches,tags,trunk} $ svnadmin create /var/svn/project $ svn import /tmp/project file:///var/svn/project -m "initial import" $ rm -rf /tmp/project
Fix permissions to the repository:
$ find /var/svn/project -type f -exec chmod 660 {} \; $ find /var/svn/project -type d -exec chmod 2770 {} \; $ chown -R root.www-data /var/svn/project
Trac and specific Subversion versions
Note that the notes below about Subversion releases below 1.6 are mostly there for historical reasons. Everyone should be using at least 1.6.x these days. We make no strong guarantee about running an old version of Subversion with a recent version of Trac, though there are good chances that Subversion 1.4 still works with Trac 1.0dev.
Note that Trac always had issues with Subversion repositories using the Berkeley DB backend. If you happen to have such a repository, it would be a good idea to switch it to the FSFS backend if you intend to use it together with Trac. See google:svn+convert+bdb+to+fsfs.
Trac and Subversion 1.4
Trac used to work well with Subversion 1.4.
This is now the oldest supported Subversion version (older versions might work, see version 105 of this page, but we make no guarantee).
I've noticed that there has been some improvements to the ra
layer … unfortunately not available yet for the Python bindings
Also, that version supports SWIG 1.3.29, but so far I used the 1.3.25 pre-generated wrappers that are bundled with the tarball.
Issue #2611 was confirmed to be still be present for 1.4 (and probably newer versions of svn as well).
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). A workaround consists to force the use of a single Python interpreter, using the "PythonInterpreter"
directive with the same argument for all the virtual hosts, as explained here.
See also: release notes for 1.4.0
Trac and Subversion 1.5
Trac works fine with Subversion 1.5. The svn:mergeinfo properties are supported since version 0.12, though if you have lots of branches and many many changesets, this could slow down the source browser (#8459). Non-inheritable mergeinfo is supported since 0.12.1 (#9622).
The new authz format is supported since 0.12.1 (#8289).
The new svn:externals format is still work in progress (#7687).
Trac and Subversion 1.6
Trac works best with Subversion 1.6. A couple of memory leaks were fixed in 1.6 and you might benefit from these fixes.
Trac and Subversion 1.7
Trac seems to work fine with 1.7.0 as well, however be sure to use Trac ≥ 0.12.3.
Trac and Subversion 1.8
Trac seems to work fine with 1.8.0 as well, however be sure to use Trac ≥ 0.12.3.
The svn:keywords
with custom keyword definitions is unsupported yet (#11364).
Trac and Subversion 1.9
Trac seems to work fine with 1.9.0 as well, however be sure to use Trac ≥ 0.12.3.
Troubleshooting
RuntimeError: instance.__dict__ not accessible in restricted mode
This is becoming one of the most frequently reported issues for Trac and the Subversion backend, when the TracModPython web front-end is used. The problem happen when Trac is running outside of the "main_interpreter" Python interpreter and can be fixed as explained in #3371:
<Location> ... PythonInterpreter main_interpreter ... </Location>
This problem can also occur when using mod_wsgi for both embedded mode or daemon mode. As documented in integrating Trac with mod_wsgi, the solution is the same as for mod_python. That is, force Trac instance to run in main Python interpreter instance. When using mod_wsgi this is done using:
<Location> ... WSGIApplicationGroup %{GLOBAL} ... </Location>
TypeError: argument number 0: a 'apr_pool_t *' is expected, 'instance(<libsvn.core.GenericSWIGWrapper instance at 0x...>)' is received
Use the same fix as above. See #2611 for more information if needed.
ImportError: /usr/local/lib/libsvn_ra_dav-1.so.0: undefined symbol: ...
This error manifests itself quite frequently with Subversion 1.4, the undefined symbol
in question may differ (gss_delete_sec_context
, SSL_shutdown
, etc.)
See the advices of Garrett McGrath in googlegroups:trac-users:1ec307bef7552e5e and also #3706.
SubversionException: ("Expected version '3' of repository; found version '5'", ...
The bindings used are older than the Subversion version used to create the repository (#3943).
SubversionException: ('No such revision XY', 160006)
This kind of error seems to happen frequently. Sometimes it seems to be related to the Trac cache being out-of-sync and needing a manual resync
(#2739, #3301, #3728); this can happen if the repository was rebuilt and its UUID hasn't changed. Sometimes it seems to be because the repository is temporarily unavailable (#2346), and sometimes, we simply don't know yet (#3773, #3861, #3875).
Unsupported version control system "svn"
By far one of our most commonly reported installation issue (search:'"Unsupported version control system"'), this simply means that the Python bindings for Subversion can't be loaded by Trac.
For Trac 1.0 (trunk) above [11082], another common cause might simply be that the components for Subversion, are not enabled, since they're now optional. See #tracopt above for more details.
If you use Debian an try this: TracOnDebianSarge
If you use FreeBSD try this:
$ sudo make FORCE_PKG_REGISTER= install clean
This can be due to a variety of reasons, and you should go through the following check list to find out.
ImportError: cannot import name * from 'svn' (.../site-packages/svn/__init__.py)
In the case the following error is logged, svn
module might be installed from PyPI. Uninstall the svn
module because it is NOT a Subversion bindings.
09:07:06 Trac[env] INFO: -------------------------------- environment startup [Trac 1.6] -------------------------------- 127.0.0.1 - - [12/Jun/2024 09:07:06] "GET / HTTP/1.1" 200 - 09:07:09 Trac[svn_fs] INFO: Failed to load Subversion bindings Traceback (most recent call last): File "/venv/lib/python3.12/site-packages/tracopt/versioncontrol/svn/svn_fs.py", line 200, in __init__ _import_svn() File "/venv/lib/python3.12/site-packages/tracopt/versioncontrol/svn/svn_fs.py", line 72, in _import_svn from svn import fs, repos, core, delta ImportError: cannot import name 'fs' from 'svn' (/venv/lib/python3.12/site-packages/svn/__init__.py)
$ pip uninstall svn
Check list
When there's some trouble using the Subversion bindings, it usually helps to perform the following checks:
- Verify that you can load the bindings using the Python interactive interpreter
If this succeeds, that's a good start.
$ python Python ... >>> from svn import core
If it doesn't, it usually means that your bindings are located in a place they can't be loaded from. So either move the
svn
andlibsvn
found in the /opt/subversion-xxx/lib/svn-python folder into your site-packages folder, or add the above folder to your PYTHONPATH, or create a svn.pth file in your Python site-packages folder with the above folder path as its single line content (an example on a FreeBSD installation, again: /usr/local/lib/pythonN.N/site-packages/). One simple solution for rpm-based operating systems, is to install the subversion-python bindings rpm. The official subversion site points here to download those packages.
For Collabnet 1.3 on Windows the solution was
set PYTHONPATH=C:\csvn\lib\svn-python
If you get the message
ImportError: libsvn_swig_py-1.so.0: cannot open shared object file: No such file or directory
even though you can see the .so file in the correct place, then tryldconfig -v
as root.
Windows Users
According to the README.txt file for the Subversion bindings, if you are using Python 2.5+ you need to rename all the .dll files in the libsvn folder to .pyd files. Upon further research, https://www.python.org/doc/faq/windows/#is-a-pyd-file-the-same-as-a-dll indicates you may need to have both the .pyd and .dll version of the libsvn files available. This resolved both the '
ImportError: No module named _core
' error (with only the DLL) and the 'ImportError: DLL load failed
' (with only the pyd) when testing from the console, and the browser. The same error ('ImportError: DLL load failed
') is reported when using apache 2.2, see #6739 for details.
Note that the bindings don't come with all the necessary files, you also need to have svn binaries (
libeay32.dll
,libsasl.dll
, etc.) available on the path. If these files aren't available, you will receive the errorImportError: DLL load failed:
. Upon investigating withdepends.exe
, I found thatcore.pyd
loaded, unloaded, then failed to load. So, when downloading from http://alagazam.net for instance, the Python bindings are not sufficient. Pick up the subversion binaries as well and put them on your PATH.
Don't use 64bit version of Python. The Subversion project does not provide amd64 or ia64 setup executables, so if you want to use Subversion integration, you’ll need to either compile the bindings yourself, or use the x86 version of Python.
A good way to diagnose a DLL load failed error is to use the depends.exe tool from the console in which you'd run python.exe, and do a
depends.exe absolute-path-to/python.exe
instead. Then, pressF7
(Start Profiling… - you need at least version 2.0 of depends.exe) and typefrom svn import core
at the Python prompt in the new cmd window. This will try to load the bindings, but this time you'll be able to see why this fails, by spotting the .DLLs shown in red in the Module list, and there are really lots of options here ;-)
When using depends.exe be sure to set the "Starting directory" to your Apache bin directory rather than the default python one. This will help when trying to figure out why python works fine, but Apache does not.
Mac OS X Users
Subversion 1.5.X defaults installs in /opt/subversion/. The svn.pth solution works up to this point, but Trac will still be unhappy: you will need to copy
/opt/subversion/lib/svn-python/svn
&/opt/subversion/lib/svn-python/libsvn
on top of/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib/python/libsvn
and/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib/python/svn
.
- Check the version
Verify that the version given back matches your expectation.
>>> (core.SVN_VER_MAJOR, core.SVN_VER_MINOR, core.SVN_VER_MICRO, core.SVN_VER_PATCH) (1, 4, 3, 3)
- Check that you're using the right binaries (Linux)
Get the pid of the above running Python interpreter (i.e. once the binding is loaded), and get the list of the libraries used by looking at the corresponding map file.
e.g.
$ cat /proc/10213/maps | grep .so | cut -d/ -f2- | sort -u
In particular, pay attention to the
.../lib/svn-python/libsvn/_core.so
file and see if its location seems to be consistent with both those of the other svn libraries (.../lib/*.so
) and the location of the Python code part of the bindings (.../lib/svn-python/svn/core.py
).
- Have you got SVN disabled in your trac.ini file?
Starting with Trac 1.0, the Subversion components need to be explicitly enabled. See #tracopt above, if you haven't yet.
Before Trac 1.0, the Subversion specific modules were always enabled, but even then it could happen that for some reason, people had explicitly disabled those and possibly forgot about it. If so, set it/them to enabled (or simply delete the offending lines, since I believe they are enabled by default.)
[components] trac.versioncontrol.api.repositorymanager = enabled trac.versioncontrol.svn_authz.svnauthzoptions = enabled trac.versioncontrol.svn_fs.subversionconnector = enabled trac.versioncontrol.svn_prop.subversionmergepropertydiffrenderer = enabled trac.versioncontrol.svn_prop.subversionmergepropertyrenderer = enabled trac.versioncontrol.svn_prop.subversionpropertyrenderer = enabled(so again, the above module
svn_fs
/svn_prop
names are only valid before Trac 1.0, see #tracopt starting from 1.0)
- If you're using Apache / mod_python (Linux/Windows) (first tip)
Get a similar list of libraries, but this time for one of your httpd process. Then compare the two, and pay attention to any difference between the
svn
libraries and theapr
libraries. You have to have compatible APR libraries between Apache and Subversion, otherwise you risk to get a wide variety of subtle errors (e.g. #4985).
- If you're using Apache / mod_python (Linux) (second tip)
If you have installed the Subversion .so-Files in some "remote" location, Apache may be unable to find them (and thus unable to pass them on to Python/Trac, such that Trac cannot find Subversion). To check if this is the case, do the following:
$ /etc/init.d/apache2 stop $ export LD_LIBRARY_PATH=/usr/lib/python/site-packages/libsvn/:$LD_LIBRARY_PATH $ /etc/init.d/apache2 restart
If this works, you need to add the library path permanently. There are two options for this. Either add it in the Apache configuration file (https://httpd.apache.org/docs/2.2/mod/mod_env.html#setenv) or at the system level by adding the path to /etc/ld.so.conf, and then run ldconfig. More information on shared libraries can be found here: https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
- if you're getting 'undefined symbol: xmlCreatePushParserCtxt' while running make check-swig-py, it could be that your libneon is compiled against libxml2. If this is the case, try to recompile your libneon against expat instead of libxml2.
- If you're using Apache - mod_python/mod_wsgi (Windows)
Try replacing the
libapr-1.dll
in the Apache bin with the version that's in Python's libsvn or Subversion's bin, just substituting seems to fix it. See #6739 for more details.
Known Issues
- #1445
- [ER] Revision Graph for the Version Control Browser
- #1947
- Nicer handling of bugtraq properties
- #2611
- Problem with SVN bindings (SVN 1.3.0, Trac r2771)
- #2880
- Ignore svn properties / trees in timeline
- #3470
- improve handling of scoped repositories with copy history
- #4474
- diffing two large trees results in a massive list with a lot of empty links
- #5246
- [PATCH] Use permission system to store groups for authz access control
- #6474
- svn:externals displayed as folder in listing
- #6615
- svn:externals not correctly displayed in browser
- #7687
- Add support for svn:externals "1.5" style
- #7744
- source:path@rev targeting a file below a copied dir may fail
- #8477
- Support SVN 1.5 merge tracking in Annotate view
- #8813
- next_rev is slow, particularly in the direct-svnfs case
- #9208
- Support for SVN repository on a UNC path on Windows
- #10058
- Highlight locked files in repository browser
- #10079
- improper rendering of svn:externals when not configured
- #10421
- RuntimeError: instance.__dict__ not accessible in restricted mode
- #10547
- glitch with mergeinfo (recreation of merge source shown as eligible)
- #11205
- "repository sync" fails for Subversion repository with unicode path
- #12121
- Subversion copies could show peg revision in browser view
- #12442
- Support per-repository authz_file
- #12549
- Provide option for blame to use merged history
- #13624
- svn-browser generates wrong links directly after renaming/moving files
Asking for More Support About Subversion
- ReadTheFineBook: https://svnbook.red-bean.com and/or the FAQ
- If you think you've found a bug in Subversion, read these instructions