Version Control with Subversion - Login

Embedding Subversionpers that translate the datatypes native to your scripting language into the datatypesneeded by Subversion's C libraries.Significant efforts have been made toward creating functional SWIG-generated bindings forPython, Perl, and Ruby. To some extent, the work done preparing the SWIG interface filesfor these languages is reusable in efforts to generate bindings for other languages supportedby SWIG (which include versions of C#, Guile, Java, MzScheme, OCaml, PHP, andTcl, among others). However, some extra programming is required to compensate for complexAPIs that SWIG needs some help translating between languages. For more informationon SWIG itself, see the project's web site at http://www.swig.org/.Subversion also has language bindings for Java. The javahl bindings (located in subversion/bindings/javain the Subversion source tree) aren't SWIG-based, but are insteada mixture of Java and hand-coded JNI. Javahl covers most Subversion client-sideAPIs and is specifically targeted at implementors of Java-based Subversion clients andIDE integrations.Subversion's language bindings tend to lack the level of developer attention given to thecore Subversion modules, but can generally be trusted as production-ready. A number ofscripts and applications, alternative Subversion GUI clients, and other third-party tools aresuccessfully using Subversion's language bindings today to accomplish their Subversionintegrations.It's worth noting here that there are other options for interfacing with Subversion using otherlanguages: alternative bindings for Subversion that aren't provided by the Subversiondevelopment community at all. You can find links to these alternative bindings on the Subversionproject's links page (at http://subversion.tigris.org/links.html), but there are a coupleof popular ones we feel are especially noteworthy. First, Barry Scott's PySVN bindings (http://pysvn.tigris.org/)are a popular option for binding with Python. PySVN boasts of a morePythonic interface than the more C-like APIs provided by Subversion's own Python bindings.And if you're looking for a pure Java implementation of Subversion, check out SVNKit(http://svnkit.com/), which is Subversion rewritten from the ground up in Java.SVNKit Versus javahlIn 2005, a small company called TMate announced the 1.0.0 release of JavaSVN—apure Java implementation of Subversion. Since then, the project has been renamedto SVNKit (available at http://svnkit.com/) and has seen great success as a providerof Subversion functionality to various Subversion clients, IDE integrations, and otherthird-party tools.The SVNKit library is interesting in that, unlike the javahl library, it is not merely awrapper around the official Subversion core libraries. In fact, it shares no code withSubversion at all. But while it is easy to confuse SVNKit with javahl, and easier still tonot even realize which of these libraries you are using, folks should be aware thatSVNKit differs from javahl in some significant ways. First, SVNKit is not developed asopen source software and seems to have at any given time only a few developersworking 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 portionsof Subversion can be reasonably cloned while still keeping up with Subversion'sreleases. This has already happened once—SVNKit cannot access BDB-backedSubversion repositories via the file:// protocol because there's no pure Java implementationof Berkeley DB that is file-format-compatible with the native implementationof that library.That said, SVNKit has a well-established track record of reliability. And a pure Javasolution is much more robust in the face of programming errors—a bug in SVNKitmight raise a catchable Java Exception, but a bug in the Subversion core libraries asaccessed via javahl can bring down your entire Java Runtime Environment. So,weigh the costs when choosing a Java-based Subversion implementation.216