Changes between Version 73 and Version 74 of TracSubversion

Timestamp:

Apr 18, 2010, 12:01:48 PM (14 years ago)

Author:

Remy Blank

Comment:

Small reformattting.

TracSubversion

@@ -210 +210 @@
 
  1. Verify that you can load the bindings using the Python interactive interpreter
-
-{{{
+ {{{
 $ python
 Python ...
 >>> from svn import core
-}}}
-If this succeeds, that's a good start.
-
-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` and `libsvn` 
-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 [http://docs.python.org/lib/module-site.html 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 [http://subversion.tigris.org/project_packages.html official subversion site] points [http://summersoft.fay.ar.us/pub/subversion/latest/ here] to download those packages.
-'''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, http://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 browswer.
-
-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 try {{{ldconfig -v}}} as root.
+ }}}
+ If this succeeds, that's a good start.
+
+ 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` and `libsvn` 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 [http://docs.python.org/lib/module-site.html 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 [http://subversion.tigris.org/project_packages.html official subversion site] points [http://summersoft.fay.ar.us/pub/subversion/latest/ here] to download those packages.
+
+ 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 try {{{ldconfig -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, http://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 browswer.
 
 
  2. Check the version
-{{{
+ {{{
 >>> (core.SVN_VER_MAJOR, core.SVN_VER_MINOR, core.SVN_VER_MICRO, core.SVN_VER_PATCH)
 (1, 4, 3, 3)
-}}}
-Verify that the version given back matches your expectation.
+ }}}
+ Verify that the version given back matches your expectation.
 
  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.
-{{{
+ 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`).
+ }}}
+
+ 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`).
 
  4. Have you got SVN disabled in your trac.ini file for some reason.
 
-For whatever reason, you may have trac.versioncontrol.* set to disabled in your trac.ini file. If so, set it/them to enabled (or simply delete the offending lines, since I believe they are enabled by default.)
-
-{{{
+ For whatever reason, you may have trac.versioncontrol.* set to disabled in your trac.ini file. 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
@@ -267 +255 @@
 trac.versioncontrol.svn_prop.subversionmergepropertyrenderer = enabled
 trac.versioncontrol.svn_prop.subversionpropertyrenderer = enabled
-}}}
+ }}}
 
 '''And if it doesnt....??'''
@@ -275 +263 @@
  3. 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 the `apr` 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).
+ 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 the `apr` 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).
 
  4. 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:
-
-{{{
+ 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 (http://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: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
-
-5. 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 this works, you need to add the library path permanently. There are two options for this. Either add it in the Apache configuration file (http://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: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
+
+ 5. 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. 
 
 == Tip for Debian Linux ==