[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