Changes between Initial Version and Version 1 of waue/TracSubversion

Timestamp:

Feb 10, 2009, 1:46:50 PM (15 years ago)

Author:

waue

Comment:

--

waue/TracSubversion

@@ +1 @@
+[[PageOutline]]
+
+= Trac and Subversion =
+此篇是修改官網的[http://trac.edgewall.org/wiki/TracSubversion Trac and Subversion]
+
+Trac has supported the [http://subversion.tigris.org 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 [wiki:TracSubversion#AskingforMoreSupportAboutSubversion more support] 
+options elsewhere.
+
+== Getting Subversion == 
+
+From subversion.tigris.org, in the [http://subversion.tigris.org/servlets/ProjectDocumentList download] area:
+ - [http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=260&expandFolder=260&folderID=91 Source] archives.
+ - Pre-built binaries for [http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91&expandFolder=91&folderID=74 Windows].
+   With Subversion 1.4.6, there are pre-built installers for Python 2.3, 2.4, and 2.5.
+ - 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 of `apr` and `apr-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 the `svn-python` folder 
+   (the one containing the `svn` and `libsvn` packages). [[br]]
+   e.g. if svn is installed in `/opt/subversion-1.4.4`:
+   {{{
+# export PYTHONPATH=$PYTHONPATH:/opt/subversion-1.4.4/lib/svn-python`
+   }}}
+   If you're using TracModPython, be sure that Apache will also see this environment variable, or alternatively use the [TracModPython#Subversionissues PythonPath] mod_python directive.[[br]][[br]]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 your `PYTHONPATH`.
+
+=== 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 /var/svn
+  $ mkdir /var/svn/project
+  $ mkdir /tmp/project
+  $ mkdir /tmp/project/branches
+  $ mkdir /tmp/project/tags
+  $ mkdir /tmp/project/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 ==
+{{{
+#!comment
+The following info  about pre 1.3.0 versions is all ''by heart'' 
+and is probably inaccurate at places. 
+This is mostly to get the page started.
+Feel free to correct me and publicly humiliate me :)
+}}}
+
+=== 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) [[BR]]
+   which can be fixed by applying this
+   [/trac/ticket/2472#change_12 patch] to
+   `subversion/bindings/swig/python/svn/core.py` [[BR]]
+   Should be fixed in Subversion 1.3.1 (!r17992).
+ * Issue #2620 (memory leak) [[BR]]
+   which can be fixed by applying this
+   [/trac/ticket/2620#change_10 patch] to 
+   `subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c`. [[BR]]
+   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, manifesting itself with `"argument number 0: a 'apr_pool_t *' is expected"` messages in the log and segfault of the apache server) [[BR]]
+   was supposedly fixed by applying this
+   [attachment:ticket:2611:application_pool_race_condition_fix.txt patch] to 
+   `subversion/bindings/swig/include/proxy_apr.swg`.
+   Note that after applying this patch, the SWIG bindings would have to be regenerated,
+   as explained [comment:ticket:2611:16 here].
+   It should be emphasized that a compatible version of SWIG
+   must be used (`1.3.24`, `1.3.25`). [[BR]]
+   The issue was supposed to be fixed in Subversion 1.3.1, as the above patch was integrated as !r18721, but actually the patch was not enough to solve the issue. See below.
+
+==== Trac and Subversion 1.3.1 ====
+
+As mentioned above, the issues found with 1.3.0 should be fixed
+by 1.3.1. This is mostly true, except for #2611.
+
+'''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[[br]]
+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). '''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 [comment:ticket:3455:5 here].
+
+==== Trac and Subversion 1.3.2 ====
+
+This version adds support for SWIG 1.3.28. 
+
+See also: [http://svn.collab.net/repos/svn/tags/1.3.2/CHANGES release notes for 1.3.2]
+
+=== Trac and Subversion 1.4 ===
+
+Trac works well with Subversion 1.4.
+
+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.
+
+Same remark as above concerning #2611, if I have some time, I'll try to reproduce the issue.
+Update: according to comment:ticket:2965:14, the problem is still there for 1.4.
+
+See also: [http://svn.collab.net/repos/svn/tags/1.4.0/CHANGES release notes for 1.4.0]
+
+== Troubleshooting ==
+
+==== `RuntimeError: instance.__dict__ not accessible in restricted mode` ==== #instance-dict-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 [http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac 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:
+{{{
+WSGIApplicationGroup %{GLOBAL}
+}}}
+
+==== `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: ...` ==== #ra_dav-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'", ...` ==== #version-mismatch
+
+The bindings used are older than the Subversion version used to create the repository (#3943).
+
+==== `SubversionException: ('No such revision XY', 160006)` ==== #no-such-revision
+
+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"` ==== #unsupported-vcs
+
+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.
+
+If you use Debian an try this: TracOnDebianSarge
+
+This can be due to a variety of reasons, and you should go through the 
+following check list to find out.
+
+==== Check list ====
+
+When there's some trouble using the Subversion bindings, 
+it usually helps to perform the following checks:
+
+ 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.
+
+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.
+
+
+ 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.
+
+ 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`).
+
+'''And if it doesnt....??'''
+
+(Mac OS X) 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. 
+
+ 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).
+
+ 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:
+
+{{{
+/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. 
+
+== Tip for Debian Linux ==
+Try to install the Subversion Bindings using apt
+{{{
+apt-get install python-subversion
+}}}
+Works for Subversion 1.4.
+
+== Known Issues ==
+
+[[TicketQuery(status=!closed&keywords=~svn&type=defect)]]
+
+== Asking for More Support About Subversion ==
+
+ * !ReadTheFineBook: http://svnbook.red-bean.com and/or the   
+   [http://subversion.tigris.org/faq.html FAQ]
+ * There's also a `#svn` channel on the `freenode` IRC network
+ * If you think you've found a bug in Subversion, read these 
+   [http://subversion.tigris.org/project_issues.html instructions]
+