When the Subversion project first launched, it was blessed to have something that many much older projects still lack: a clear direction. It would have been easy — and certainly the temptation existed — to try to make Subversion all things to all people. Why settle for "a compelling replacement for CVS" (which was the goal at the time) when we could shoot for "best-of-class version control"? "Next-generation SCM solution"? "All that and a bag of chips?" Here's why: so the developers could get anything accomplished at all. It's as the old Proverb says (though admittedly in a different context), "Where there is no vision, the people perish." Without a single, clear sense of direction, you're left either meandering about with no sense of direction at all or (worse) stalemated by N senses of opposing directions. So how do the leaders of an open source software project choose a direction and set goals? And where do you, the reader, fit into all of this? Read on.

This is actually old news now, but Subversion 1.5.1 was released a few weeks ago.  As with just about any .1 release, I highly recommend it, and if you were waiting to upgrade, now may be the right time.  CollabNet has refreshed all of its binary packages, so go get 'em.  Judging by the download numbers we have seen, most of you have figured this all out already.

There are a few enhancements in our packages based on feedback from users.

For our Linux RPMs, we discovered that the package auto-dependency feature was causing our RPMs to advertise that they provide a number of libraries.  However, given that our package installs into a private location, this is not a good thing, as it can prevent other packages from properly installing the dependencies they need.  So we have fixed this, and re-released our 1.5.1 RPMs.  Current version should be 1.5.1-2.  64-bit RPMs can be obtained here.

For our Solaris packages, we discovered that we were depending on some external packages that we did not intend to.  One was SMCiconv and the other was SUNWlibsasl.  The former was particularly bad since it comes from sunfreeware.com and not Solaris.  Our build images all have this package installed because it comes with the gcc build we use from that site.  Consequently, we did not pick up on this in our testing.  Anyway, we have fixed this so that we now provide our own builds for APR-ICONV and SASL as we do on Linux.

For our Windows installer, the main thing we had to deal with was upgrading a server from either 1.4.6 or 1.5.0.  Since the two versions used different versions of Apache it took a while to nail down the way we wanted this to work.  We have it right now, and the installers were posted yesterday.

Finally, on OSX, we were using the libsasl that comes with OSX.  This turns out to have some problems that prevented the svn+ssh protocol from working.  We have fixed this problem by building and including our own versions of the SASL library.

Anyway, thanks for the feedback on the packages.  It is not as easy as it sounds to get these things right across several operating systems.