Core Subversion Developer Moves To Google

Ben Collins-Sussman, a core Subversion team member, announced yesterday that he will be leaving CollabNet and moving on to new opportunities, apparently at Google.

Ben was one of the first members of the Subversion team, along with Karl Fogel and Jim Blandy.

I’d like to wish Ben good luck in his new opportunity and give him a personal thanks for the work he’s done to bring the Subversion product to the point it is today. The product and community would not be where it they are today without his work — both in the code itself and the work he did in the community providing support (and even an occasional Python script) to help us out during our Subversion implemention.

Good luck Ben and thanks for all of your contributions to a great product!

By the way, you can also read the announcement on Bens weblog.

The Final 72 Hours of Blastwave?

I hit on a message on the Subversion mailing list that there were Solaris packages for the latest version of Subversion on a site called Blastwave. This is a site I had never heard of and thought it was pretty cool that the latest version of the Subversion distribution was available so quickly on a site.

I had this message bookmarked in my mail to go back to later. As I hit the site this morning I found a message on the title page about the possible closing of the site due to lack of funding. Apparently, the operators have been trying to get corporate funding for this service for a while to no avail.

I would think this would be something Sun would want to contribute to given their recent opening of the Solaris Operating System to garner support. Apparently it is already a well established community dedicated to more than just the version of Solaris just opened, but supports packages for earlier versions of Solaris as well.

This is pretty sad. For the longest time I had frequented until performance made it more cost effective for me to build the software on my own. If blastwave has decent performance and gets the most recent packages for a given software suite built as quickly as they did for Subversion 1.2.3, it would be in the Solaris communities best interest to support it.

This is the biggest problem I think we have right now. While the internet is a commons that anyone can contribute to, it is very difficult to fund efforts like this that provide a community service without a revenue model behind it.

Subversion 1.2.1 released.

The Subversion team has released version 1.2.1 of their version control system.

The following changes are included in this release:

– Client:
* fixed: ‘svn lock’ on switched file locks wrong thing (issue #2307)
* fixed: ‘svn (un)lock’ errors on multiple targets (r14736, 14775)
* fixed: ‘svn (un)lock’ problems with URI-unsafe names (issue #2314)
* fixed: ‘svn (un)lock’ not caching authentication (r15088)
* fixed: ‘svn unlock’ loses executable bit (r14859, r14923, r14939)
* fixed: ‘svn unlock URL’ segfault (r14893)
* fixed: ‘svn commit’ failure on XML-unsafe locked paths (issue #2335)
* fixed: recursive directory copy bug (issue #2343)
* fixed: don’t initialize RA library in ‘svnversion’ (r14755)
* fixed: svn-push segfault (r14732)
* various translation updates for localized client messages

– Server:
* fixed: ‘svn log’ performance regression, general (r14116, 14772, 14759)
* fixed: ‘svn log -v’ performance regression, FSFS-specific (r15016)
* fixed: mod_dav_svn bug sets content-type incorrectly (r15046)

* fixed: win32 innosetup’s add/repair/remove features (r14830)
* fixed: OBOE with ‘limit’ parameter of svn_repos_get_logs3(). (r15119)
* redhat RPM fixes (r15050)
* perl bindings:
– accessors for svn_lock_t (r15082)
– call utf_initialize, adjust global pool usage (r15076, r15080,
r15081, r15117)

You can download the software at one of the following links:

Building Subversion 1.2 on Solaris 9

I’ve just spent a couple of days trying to get Subversion to build on a Solaris 9 environment. For some reason, it wasn’t as easy as it has been in the past and I’ve had a boat load of trouble, so I wanted to document the final solution I came to.

The Source Control System

We are running Solaris 9 and access the Subversion repository via HTTP/HTTPS through Apache. This means that I have to compile in SSL support for the client, in addition to mod_svn_dav support for the Apache Server. We also use the mod_svn_authz module for access control to the repository.

Software installed On The System

The following software is installed on the system:

Description of the Problem

The normal process I use for building these components is the following:

  1. Download the source tarball
  2. Untar the contents of the tarball to the a /tmp/subversion directory
  3. Configure the software with the following commands:
    ./configure --with-ssl --with-berkeley-db=/usr/local/BerkeleyDB4.2 
  4. Build the software with the make command

The software builds until it hits the neon module, after which I would receive pages of the following errors:

make[1]: Entering directory `/tmp/subversion-1.2.0/neon'
cd src && make
make[2]: Entering directory `/tmp/subversion-1.2.0/neon/src'
/bin/bash ../libtool --quiet --mode=link gcc -rpath /usr/local/lib
-version-info 24:7:0
-o ne_request.lo ne_session.lo ne_basic.lo ne_string.lo ne_uri.lo
ne_dates.lo ne_alloc.lo ne_md5.lo ne_utils.lo ne_socket.lo ne_auth.lo
ne_cookies.lo ne_redirect.lo ne_compress.lo ne_207.lo ne_xml.lo
ne_props.lo ne_locks.lo ne_acl.lo
ne_openssl.lo -lssl -lcrypto -lnsl -lsocket
-lz /tmp/subversion-1.2.0/apr-util/xml/expat/lib/
Text relocation remains referenced
against symbol offset in file
0xd44 /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd48 /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd4c /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd50 /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd54 /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd58 /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd5c /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd60 /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd64 /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd68 /usr/local/ssl/lib/libssl.a(t1_enc.o)

When I saw the errors streaming across the screen, I remembered that I had gotten them before. To fix them previously, I changed into the neon directory and typed the following:

./configure --with-ssl --disable-shared

This had previously fixed the problem (I have no idea why). This time it didn’t and after rebuilding I had the same results.

Finally Getting Things To Build

On a fluke, I decided to run the shell script file in the neon directory and reconfigure neon, enabling shared libraries. Then I went back up to the root of the tree and built again. This time the software built cleanly and all tests ran successfully.

Installing The Software

Since I finally had a clean build and all tests had ran successfully, I decided to go ahead and install it. Upon installing it I received errors that linking failed on the shared libraries being installed and I had to relink everything. This pretty much rendered my source control unuseable until I could figure out why linking failed. Just to be clear, this was not on the production repository box, but on another Solaris machine.

I went through my /usr/local/bin and /usr/local/lib directory and removed every libsvn* shared library, all apr and apr-util shared libraries and all neon libraries that were present on the system. Once this completed, I was able to install the software successfully.

One of the symptoms of old libraries in the path or linking errors is the ‘undefined symbol’ error some have reported on the mailing list when upgrading. When you run into an error like this, you might want to try finding and removing all of these libraries as stated above, as this is an error I was getting as well. Removing the old directories and running make install fixed the problem.


This install was pretty painful. I attribute most of the pain to the fact that I was doing most of this work between meetings, so the constant start / stop took a toll on entering “flow state” to really think about the problem. As I was experiencing these problems, I couldn’t find any really good write ups on installation of the Subversion software on Solaris, so I figured I’d throw this together in the event that someone else was experiencing this level of frustration. Plus, I figure it will help me next time I need to do this to have an actual documented process to follow.

A summary of what I did follows, for those who don’t want to wade through this whole post again:

  1. After exploding the tarball, change to the neon directory and run
  2. Run the configure script with your desired options
  3. Build the software
  4. Run make check and ensure all of your tests pass
  5. Take the server down
  6. Back up your current installation
  7. Remove your old Subversion, apr, and neon libraries from the installed version
  8. Install the software
  9. Bring the server up
  10. Test

On the bright side, I also upgraded a SuSE 9.1 box to the new software. This took about five minutes after I found these RPM packages for SuSE 9.1.


Subversion 1.2.0 Release Candidate 2 released.

I’m a little behind on this one, but on April 25, the Subversion team announced the release of Subversion 1.2.0 release candidate 2.

Since I’m so late in getting this up here, the Win32 binaries are also available, according to this announcement on the mailing list.

If you are curious as to the changes in 1.2.0, check out the release notes.

For downloads, you can pull binaries and source from the project download area.