[svnbook commit] r2932 - trunk/src/en/book
cmpilato
noreply at red-bean.com
Sun Dec 16 00:59:46 CST 2007
Author: cmpilato
Date: Sun Dec 16 00:59:44 2007
New Revision: 2932
Log:
Fix some typos and add a sidebar about SVNKit.
Modified:
trunk/src/en/book/ch08-embedding-svn.xml
Modified: trunk/src/en/book/ch08-embedding-svn.xml
==============================================================================
--- trunk/src/en/book/ch08-embedding-svn.xml (original)
+++ trunk/src/en/book/ch08-embedding-svn.xml Sun Dec 16 00:59:44 2007
@@ -887,10 +887,10 @@
url="http://www.swig.org/"/>.</para>
<para>Subversion also has language bindings for Java. The
- JavaJL bindings (located in
+ javahl bindings (located in
<filename>subversion/bindings/java</filename> in the
Subversion source tree) aren't SWIG-based, but are instead a
- mixture of javah and hand-coded JNI. JavaHL most covers
+ mixture of Java and hand-coded JNI. Javahl covers most
Subversion client-side APIs, and is specifically targeted at
implementors of Java-based Subversion clients and IDE
integrations.</para>
@@ -915,13 +915,52 @@
url="http://pysvn.tigris.org/" />) are a popular option for
binding with Python. PySVN boasts of a more Pythonic
interface than the more C-like APIs provided by Subversion's
- own Python bindings. For folks looking for a pure Java
+ own Python bindings. And if you're looking for a pure Java
implementation of Subversion, check out SVNKit (<ulink
url="http://svnkit.com/" />), which is Subversion re-written
- from the ground up in Java. You should exercise caution here,
- though—because SVNKit doesn't use the core Subversion
- libraries, it's behavior is not guaranteed to match that of
- Subversion itself.</para>
+ from the ground up in Java.</para>
+
+ <sidebar>
+ <title>SVNKit vs. javahl</title>
+
+ <para>In 2005, a small company called TMate announced the
+ 1.0.0 release of JavaSVN—a pure Java implementation of
+ Subversion. Since then, the project has been renamed to
+ SVNKit (available at <ulink url="http://svnkit.com/" />)
+ and has seen great success as a provider of Subversion
+ functionality to various Subversion clients, IDE
+ integrations, and other third-party tools.</para>
+
+ <para>The SVNKit library is interesting in that, unlike the
+ javahl library, it is not merely a wrapper around the
+ official Subversion core libraries. In fact, it shares no
+ code with Subversion at all. But while it is easy to
+ confuse SVNKit with javahl, and easier still to not even
+ realize which of these libraries you are using, folks should
+ be aware that SVNKit differs from javahl in some significant
+ ways. First, SVNKit is not developed as open source
+ software, and seems to have at any given time only a few
+ developers working on it. Also, SVNKit's license is more
+ restrictive than that of Subversion. Finally, by aiming to
+ be a pure Java Subversion library, SVNKit is limited in
+ which portions of Subversion can be reasonably cloned while
+ still keeping up with Subversion's releases. This has
+ already happened once—SVNKit cannot access
+ Berkeley-DB-backed Subversion repositories via the
+ <literal>file://</literal> protocol because there's no pure
+ Java implementation of Berkeley DB that is file format
+ compatible with the native implementation of that
+ library.</para>
+
+ <para>That said, SVNKit has a well-established track record of
+ reliability. And a pure Java solution is much more robust
+ in the face of programming errors—a bug in SVNKit
+ might raise an Exception, but a bug in the Subversion core
+ libraries as accessed via javahl can bring down your entire
+ Java Runtime Environment. So, weigh the costs when choosing
+ a Java-based Subversion implementation.</para>
+
+ </sidebar>
</sect2>
More information about the svnbook-dev
mailing list