The first set of our binaries for CollabNet Subversion is now available.  Specifically, the RPM's for Red Hat Enterprise Linux.  You can get them here:

http://www.collab.net/downloads/subversion/redhat.html

These are certified to run on all 32-bit versions of RHEL 4 and 5.  In my experience, they run fine on any version of Linux that allows you to install an RPM.  I have even used them successfully on Ubuntu and Debian by using the alien package, which allows RPM to be installed on Debian systems.

Starting with this release of CollabNet Subversion, our Linux RPM's are now signed.  You can (and should) download and import the GPG key they were signed with.  This was something several of our customers had asked for.  See the readme for the Linux binaries for details and instructions.

As I mentioned in yesterday's post, we plan to have the Windows binaries available next week.  Currently it looks like they should be available sometime on Monday.  The Solaris binaries will be posted around the end of the week.

We are pretty excited about this release of the binaries.  We put a lot of effort into improving them and what we include in the packaging.  Here are some highlights:

• Standardized set of dependencies across platforms.  Apache 2.2.8, APR 1.2.12, Neon 0.28.2.  Our Windows binaries initially went out with Apache 2.0 so we wanted to wait for Subversion 1.5.0 to make the switch.  There are upgrade considerations in moving from Apache 2.0 to 2.2 that Windows users will have to consider.
• ViewVC included!  This is the biggest feature.  Not only do we include ViewVC 1.0.5, but we configure it for you automatically (if you ask us to).  It has never been easier to integrate this excellent tool into your environment.
• Python bindings are included.  These are needed for ViewVC, but also allow you to use hook scripts that require the bindings, such as the commit email hook script.
• JavaHL bindings are included with the client.  This makes it easier than ever to use JavaHL on all supported platforms, which means it is also easy to use the CollabNet Desktop and our exciting new Merge Client.
• SASL support is included in the client and server.  This is a new feature in 1.5.  There is not a lot of information out there on how to build and include it.  We have figured it out though, and include it in our package.
• We package the svn-populate-node-origins-index program so that you have the tools you need to migrate existing repositories to Subversion 1.5.
• As always, we provide packages using the native packaging format for each operating system.

These are the main enhancements I can think of, but we have been working on these improvements throughout the Subversion 1.5 life-cycle.  Those of you that participated in our Beta program have likely already experienced some of these new features and seen the packages evolve over the life of the program.  Probably the biggest benefit of our packages is that we test and certify the entire stack that we provide to you.  We do this so that we can provide the level of support that our customers ask for and so that we can be confident that we can deliver on the SLA that we provide to our customers.

Anyway, look for those Windows and Solaris binaries next week.  Also, stay tuned for some additional major new enhancements we will make to the packaging over the course of the summer.  That is all I will say for now, but details will be coming out as we roll out these enhancements.

I am pleased to announce that Subversion 1.5.0 was released today.  It has been a long journey to get to this point, but I think the final result will be worth it.  Subversion 1.5.0 is the biggest release since 1.0 and begins a new chapter in the project's evolution.  An event this big probably calls for some profound comments and reflection.  Perhaps, I or others, will make some at some point in the future.  Unfortunately, for myself, and a lot of people at CollabNet, the release means a lot of work and activity.

We have put together a page with links to lots of resources and information about the release:

http://www.collab.net/products/subversion/subversion15.html

I'd particularly urge you to checkout the training materials that have been created for this release.  While Subversion 1.5 is compatible with older clients and servers, to take full advantage of all the features, particularly merge tracking, there are some steps you need to take.  The training courses we have created cover these issues and can help guide you through the upgrade process.

Probably the number one thing people are looking for is binaries.  I assure you they are coming.  CollabNet's binaries are certified and that process cannot begin until the official release is made.  So our team is hard at work building and certifying the binaries.  The tentative certification schedule is:

Linux: June 20
Windows: June 24
Solaris:     June 26

There is a pretty good chance that the Windows client will be available sooner.  I will add a new blog post once the Windows binaries are posted.  BTW, the OSX binaries are ready and just waiting for the web site to be updated.  Those binaries are not certified so can be released sooner.  A lot of us at CollabNet, myself included, use them for our daily work though.

Binaries of Subversion 1.5 - Release Candidate 9 are posted. As I wrote last week, this Release Candidate does not reset the soak period. An API issue was already discovered in RC9 and RC10 will likely come later this week. RC10 won't reset the soak period either, so we are still looking at a likely Subversion 1.5 release next week. As always: unless a showstopper is found.

If you are a regular reader of this blog, you know the drill: please download the binaries and test the latest Subversion 1.5 Release Candidate. You can ask questions and report issues in our forum.

This morning we posted binaries of the Subversion 1.5 Release Candidate 8 (RC8). Compared to RC7 this release candidate contains a few translation updates and an API compatibility fix that does not affect the command line.

Another release candidate with minor changes might come. Yesterday RC9 was proposed (based on build r31577). RC9 fixes a potential issue in the working copy when you checkout with the new –-depth feature. RC9 is “out for signatures,” meaning that the Subversion developers are voting whether or not to release it. We’ll keep you updated.

Considering that the changes in RC8 and RC9 are minor and unlikely to destabilize, the Subversion developers decided not to restart the soak period (the time to test a Release Candidate before it is called the final release). So, unless users find showstopper bugs, Subversion will probably release next week or the week after.

You can download RC8 binaries from openCollabNet (Windows, Red Hat Linux, and Mac OS X). Please test RC8 and report any issues in the forum.

Btw: The release notes for Subversion 1.5 are nearing completion. You can view the Subversion 1.5 release notes on Tigris.org. A full list of SVN 1.5 changes is available as well. Neither of these documents is final of course.

Subversion 1.5.0-rc7 was released today.  As with all the previous milestones, CollabNet  provides binaries for various operating systems for you to try the release.

This is expected to be the final release candidate and the official 1.5.0 release should happen in roughly 10 days if all goes well.  Bugs reported on this release candidate will likely be addressed in a 1.5.1 or other follow-up release.  Exceptions might be bugs that are considered serious regressions or API incompatibilities.

Fixes included since the last rc are fairly minor.  They were mostly documentation fixes in the code and some minor bug fixes.  Probably the most significant change was to the new API for including arbitrary revision properties in a commit.  During review of this API it was decided that there was a cleaner way to implement it, and so a change was made before the release became final.  Since it is a public API, once it is included in an official release we would have to support it until the 2.0 release, and this was deemed significant enough to get it in before the release is public.  This API change also led to a number of corresponding changes in the JavaHL API and the other language bindings.

As with the previous release candidates, we appreciate your testing and feedback.  A number of bug fixes have been made since the 1.5.x branch was created that came from users who tested these early releases.

Earlier this week, the Subversion community issued an RC5 release with the latest round of fixes. As we have done with previous releases, CollabNet is providing binaries for Windows, Linux, OSX and Solaris. The CollabNet Merge client and Subclipse have both been updated as well.

Here is a list of some of the noteworthy fixes I see (in order they were backported):

• r30741
  Fix bug whereby 'svn status --depth=files' still showed some dirs.
• r30743, r30751
  Fix memory leak in recursive remote propget.
• r30776, r30777, r30779
  svndumpfilter drops mergeinfo when it is *not* run with --renumber-revs.
• r30666, r30684, r30726
  Fix for issue 3181. Compare repository UUID with working copy when opening RA session
• r30761, r30762
  Fix for issue 3172. 'log -g' fails the moment it encounters a bogus mergeinfo which claims a merge from a non-existentpath@REV1-REV2.
• r30820
  Fix pool issue which definitely can lead to assertion failures in reintegrate, and quite possibly to other mergeinfo corruption.
• r30868, r30871
  In svnserve, tolerate unreadable passwd files. Don't error over svn+ssh:// when the user can't read passwd.
• r30843
  Fix abort in ra_serf when server sends invalid xml during replay.
• r30907
  Fix for issue 3185. Fix the 'log --limit' compatability code in ra_svn, ra_serf, and ra_neon to ignore nested logs when in '-g' mode.
• r30883, r30888
  Fix issue 3187. Fix reverse merges where merge target or subtree has non-inheritable revision ranges intersecting with the merged range.
• r30931
  Remove 'blind deletion of argument to mkdir --parents', delete only if this invocation has created it.
• r30896, r30905
  Make Cyrus SASL client support DIGEST-MD5.
• r30986
  Fix potential segfault in svn_io_remove_dir2(path='.').
• r29191, r29398, r29833, r30663, r30963, r30964
  Improve the responsiveness and accuracy of 'svn log -g'.

On April 24th, the Subversion development community released the first official release candidate for Subversion 1.5.  You can see the official announcement in this mailing list post.  You will notice that this release is labelled as RC4, and you might be wondering if you missed the RC1-3 announcements.  The answer is no, this is the first official release.  We go through an internal review period before we post any release.  Committers build and test the release and then either vote to approve or veto the release candidate.  In each of the first three tries someone saw something they did not like and so we vetoed the release.  Since version numbers are cheap, we simply increment when we try again.  That way, there is never any confusion about what someone is using.

Anyway, this is the biggest milestone for the release, short of the final GA.  The release of this release candidate can start the official soak period, which lasts a minimum of four weeks.  You can read about our release-stabilization process in the hacking guide we host on the web site.  As part of getting to this release candidate stage, we now have the release notes finalized, and you can see those online as well.  There is a lot of good overview information about the release in that document.

As we have been doing throughout the 1.5-development lifecycle, CollabNet is providing binaries for this release.  We want to make it as easy as possible for users to test the release and provide us with feedback.  Please provide the feedback, including positive feedback, as it helps us know that people are actually testing the release candidate during the soak period.  Sometimes if we do not get much feedback we will extend the soak period a little longer in order to allow time for people to try it.  So if you find bugs, please report them, and if things are working out well, then tell us that too so that we know you tried it.  Feedback can be reported on our forums on openCollabNet, or on the Subversion users mailing list on tigris.org.

In addition to getting the Subversion binaries, you can also try our new graphical merge client for Subversion 1.5 (based on Subclipse) and we also have links to the 1.5 release for TortoiseSVN and other tools.  It would be great if you could also try these tools out and give us and the developers your feedback.

CollabNet now hosts and supports AnkhSVN, the Subversion plugin for Visual Studio. Some of our goals are to help the AnkhSVN community grow and accelerate the development of the plugin. To kickstart this, we started by collaboratively creating a roadmap for AnkhSVN. Subversion 1.5 compatibility is number one on that roadmap, including good merge support. To properly support Subversion 1.5, we either needed to update our internal C# Subversion binding (NSvn) or take advantage of SharpSvn, a .NET binding for Subversion. We chose the SharpSvn route. To understand why, let's learn more about SharpSvn.

SharpSvn is a project started by Bert Huijben, who is also an AnkhSVN committer. The purpose of SharpSvn is not only to bring Subversion's API to .NET but also to abstract the low-level Subversion API away from the developer while still conforming to Microsoft's common language specification. The result is that SharpSvn is a Subversion client binding for .NET that works with a .NET 2.0 application or newer.  (Note: Since Subversion 1.5 and its final API is not yet complete, SharpSvn's APIs can change before the final release.) 

To show the value of what SharpSvn can bring to any .NET-based Subversion application, I created a simple Subversion Log Viewer using SharpSvn.

When you download and view the Log Viewer source, you'll see a lot of code that is primarily related to the UI and threading. I only use a few of SharpSvn's classes:

 
• SharpSvn.SvnTarget: Use this class as a target to run Subversion functionality against.
 
• SharpSvn.UI.SharpSvnUI: This class provides access to SharpSvn's built-in UI, for example when you are prompted for credentials or need to accept an SSL certificate.
 
• SharpSvn.Client: This is the actual client abstraction that gives you access to Subversion client functionality.
 
• SharpSvn.SvnLogEventArgs: Use this class to handle the events returned by SvnClient.Log().
 
• SharpSvn.SvnChangeItem: Use this class for objects that hold information about changed items retrieved via SvnClient.Log().

And here is a major part of the SharpSvn code in the example:

/// <summary>
/// Retrieves the Subversion log entries and potentially updates the
/// DataGridView in a streaming fashion.
/// </summary>
private void retrieveAndRenderLog()
{
    .....
    // The Subversion target to run log against
    SvnTarget target;
    
    // Attempt to create an SvnTarget by parsing the targetPath
    if (string.IsNullOrEmpty(targetPath) ||
        !SvnTarget.TryParse(targetPath, out target))
        {
            .....
        
        // SvnClient is disposable, using makes sure it's disposed every time
        using (SvnClient client = new SvnClient())
        {
            // Bind the SharpSvn UI to our client for SSL certificate and credentials
            SharpSvn.UI.SharpSvnUI.Bind(client, this);
            
            try
            {
                // Run the log subcommand
                client.Log(target,
                delegate(object lSender, SvnLogEventArgs le)
                {
                    .....
                    // Iterate over each changed path for each log entry
                    foreach (SvnChangeItem path in le.ChangedPaths)
                    {
                        tooltip.AppendLine("");
                        tooltip.Append(path.Action + " " + path.Path);
                        
                        if (path.CopyFromRevision != -1)
                            tooltip.Append(" (" + path.CopyFromPath +
                                "[" + path.CopyFromRevision + "])");
                    }
                    ..... 

SharpSvn is very performant and a simple to use API when writing .NET-based Subversion applications.  It is  easy to figure out what classes/APIs are necessary to get things done and the documentation in the SharpSvn project, and help provided on #ankhsvn (the irc.freenode.net channel for AnkhSVN), allowed me to put together the example application in less than an hour.  You will also be happy to know that SharpSvn alleviates the need for you to manually maintain the authentication callbacks, baton objects, aprpools and other low-level things that you are left dealing with while using other language bindings.

The SharpSvn's client API is completely in sync with the Subversion 1.5 client API and is the core of the future AnkhSVN 2.0 release. The code quality and completeness of SharpSvn is impressive. If you want to get involved with the development of SharpSvn, visit the project on openCollabNet.

The Subversion project has issued a beta1 release on the path to the final GA. The next release will likely be rc1 but, as always, that depends on the feedback we get from testers.

CollabNet has created binaries for Linux, Windows and Solaris (with OS X coming soon) from this beta1.  A noteworthy change as we get closer to RC1 is that we are now providing our CollabNet Subversion packaging for all three platforms. Solaris and Windows are new with this beta release. In addition, for all three of these platforms the server installation can automatically install and configure ViewVC as part of the server installation.

You can download these binaries from openCollabNet. There are also updated versions of the CollabNet Merge Client, Subclipse and TortoiseSVN available on this site.

We have a forum where you can post questions, comments or problems that you encounter using this version. If after some discussion a report is indeed deemed a defect, we forward the bug to the Subversion community using their normal processes. Feedback on the GUI merge clients will go to CollabNet Engineering.

For those that missed the announcement of the Alpha2 release, here are a few things to be aware of:

• Subversion 1.5 client has an updated working copy format. Once an SVN 1.5 client updates a working copy it will be converted to the new format. This means that older SVN clients will no longer be able to read these working copies. So either be careful, or be sure to update all your clients to the same version. There is a Python script that you can use to downgrade your working copy to the 1.4 format.
• Subversion 1.5 server can be used to serve an existing repository, but you will not be able to use the new merge tracking features with this repository until it is upgraded. You have a few options here:
1. Dump existing repository, then create a new repository using the 1.5 binaries and load the dump file.
2. Create a new repository using 1.5 binaries and use svnsync 1.5 binary to transfer the contents to the new repository.
3. Run a new command svnadmin upgrade to upgrade an existing repository. This runs fast as it just updates the internal repository format. There are some downsides to this approach though:
• SVN 1.5 repositories maintain a new index called the node-origins index  This is needed to speed up certain merge operations. The index will be lazy-populated on upgraded repositories, but can be updated on demand by running a new tool named svn-populate-node-origins-index(.exe). If you have a large repository you will likely want to populate the index. New repositories, or ones that are dumped/loaded or svnsync'ed will not need this.
• For fsfs repositories, the node-origins index will be slightly faster and take up less disk space if the repository is reloaded or synced. For existing repositories, the index has to be maintained in a separate set of files that takes up extra disk space and I/O.
• For new 1.5 fsfs repositories, there is a new sharding mechanism for storing revisions on disk. Instead of storing all revisions in one single directory, they are now spread across multiple directories which will be better on certain filesystems.  There is a Python script you can run to shard an exising fsfs repository though.
4. If you were using an earlier version of the 1.5 binaries, note that the on-disk format of the repository has been changed in the most recent builds. You should dump your repository with your current binaries, then install the new binaries, create a new repository and load the repository.

Please take the opportunity to give these beta versions on the path to GA a try. Your feedback will lead to a better final release and likely also help us deliver Subversion 1.5 as soon as possible.

The Subversion project has issued an alpha2 release on the path to the final GA. The next release might be alpha3, it might be beta1, that depends on the feedback we get from testers. One thing is certain, and that is the sooner we can find any remaining bugs, the sooner the GA release will be available.  Likewise, hearing that you have used this version with some success will also help us make decisions.

CollabNet has created binaries for Linux and Windows (with OS X coming soon) from this alpha2. You can download them from openCollabNet. There are also updated versions of the CollabNet Merge Client, Subclipse and TortoiseSVN available on this site.

We have a forum where you can post questions, comments or problems that you encounter using this version. If after some discussion a report is indeed deemed a defect, we forward the bug to the Subversion community using their normal processes. Feedback on the GUI merge clients will go to CollabNet Engineering.

A few things to be aware of:

• Subversion 1.5 client has an updated working copy format.  Once an SVN 1.5 client updates a working copy it will be converted to the new format. This means that older SVN clients will no longer be able to read these working copies. So either be careful, or be sure to update all your clients to the same version. There is a Python script that you can use to downgrade your working copy to the 1.4 format.
• Subversion 1.5 server can be used to serve an existing repository, but you will not be able to use the new merge tracking features with this repository until it is upgraded. You have a few options here:
1. Dump existing repository, then create a new repository using the 1.5 binaries and load the dump file.
2. Create a new repository using 1.5 binaries and use svnsync 1.5 binary to transfer the contents to the new repository.
3. Run a new command svnadmin upgrade to upgrade an existing repository. This runs fast as it just updates the internal repository format. There are some downsides to this approach though:
• SVN 1.5 repositories maintain a new index called the node-origins index  This is needed to speed up certain merge operations. The index will be lazy-populated on upgraded repositories, but can be updated on demand by running a new tool named svn-populate-node-origins-index(.exe). If you have a large repository you will likely want to populate the index. New repositories, or ones that are dumped/loaded or svnsync'ed will not need this.
• For fsfs repositories, the node-origins index will be slightly faster and take up less disk space if the repository is reloaded or synced. For existing repositories, the index has to be maintained in a separate set of files that takes up extra disk space and I/O.
• For new 1.5 fsfs repositories, there is a new sharding mechanism for storing revisions on disk. Instead of storing all revisions in one single directory, they are now spread across multiple directories which will be better on certain filesystems.  There is a Python script you can run to shard an exising fsfs repository though.
4. If you were using an earlier version of the 1.5 binaries, note that the on-disk format of the repository has been changed in the most recent builds. You should dump your repository with your current binaries, then install the new binaries, create a new repository and load the repository.

Please take the opportunity to give these alpha versions on the path to GA a try. Your feedback will lead to a better final release and likely also help us deliver Subversion 1.5 as soon as possible.

CollabNet is conducting a short Subversion survey, asking questions about new functionality you would like to see, your deployment of Subversion and support you need (whether it is technical, or to convince management that your company should standardize on Subversion).

Take the Subversion Survey.
 

New Subversion 1.4.6 Universal binaries for Mac OS X are now available for download from openCollabNet.  Compared to my 1.4.4 release, there are some changes based on feedback from users worth mentioning:

Project Packaging

The package of the binary has changed. The 1.4.4 release installed everything in /usr/local which made the package difficult to uninstall. The 1.4.6+ package installs Subversion into /opt/subversion for easy management and coexistence with other installations. The 1.4.4 packaging also included unnecessary files like header files. While my intentions were good, the delivery wasn't and I removed all developer-centric files from the binary. The reason for this is two fold: It makes life easier for Subversion developers and it makes the package smaller. These changes do not impact the functionality of the binary.

Previous Package Backups

When packaging a binary, many things come into play when it comes to installation.  Do I overwrite existing artifacts with my own?  Do I remove previous artifacts? Etc. The 1.4.6+ installer installs Subversion in a non-destructive fashion. The idea is to make the existing environment ideal for installation while allowing for easy rollback of the installation.  That said, the 1.4.6+ installer "backs up" any existing Subversion installations found in /usr/local and /opt/subversion to a documented location allowing for an easy way to keep old installations around for whatever the reason may be.

Other than these two items, the binary delivers the same great taste as before.  For those of you that didn't install the previous package, here is a short summary of all features of this installer:

• Installation is a fully-featured Subversion 1.4.6 installation
• Installation is Universal so you can run on any OSX-supported architecture (Intel and PPC)
• Installation includes both repository data stores (Berkeley DB and FSFS)
• Installation includes all repository network access layers (DAV and SVN)
• Installation includes all language bindings maintained by the Subversion project (Java, Perl, Python and Ruby)
• Installation includes Apache server modules (2.2.x)

As with previous releases of this binary, the svnbinaries project on openCollabNet is the place for feedback, bugs and questions. 

Special thanks go to pr3d4t0r for helping with testing and pakacging on an Intel-Mac.

P.S. - There are many of you requesting Subversion 1.5.0 beta builds for OSX.  Now that I have the 1.4.6 binary out of the way, I will work on getting 1.5.0 beta binaries out within the next week or so.

A few weeks back I asked in this blog that readers nominate (and later vote for) Subversion in the developer.com product of the year award. Big thanks to everybody who followed up: Subversion won the "Developer.com Product of the Year 2008" award in the "Open Source Tool" category.

Here is a comment that one of the people who voted for Subversion made: “Ease of use, the ability to support distributed teams without any administration headaches, and enterprise-class scalability have made Subversion the preferred solution for many distributed projects.”

Well, I can certainly agree with that. Subversion continues to prove its strengths as the software configuration management solution of choice for teams of many sizes, and specially those that are distributed over different locations. At CollabNet we see daily how users of Subversion successfully manage SCM for their distributed teams, whether they use Subversion stand-alone or as part of one of our enterprise platforms, such as SourceForge Enterprise Edition.

Congratulations to the open source development team and everybody involved with Subversion.

Sometimes finding open source software for AIX can be a pain. Finding binaries is hard enough, and then they might be out of date. Subversion binaries for AIX have suffered this fate until now and I am proud to announce the availability of Subversion 1.4.6 AIX binaries, a free download from openCollabNet.

These new AIX binaries are a complete Subversion 1.4.6 installation. The server includes support for all repository data stores and all repository access layers. The binaries even ship with Apache 2.2.x modules and the Python language bindings.

You'll notice the binaries do not include the Java, Perl or Ruby bindings. Due to the complexity of building these, we've decided not to ship them in our initial release. The AIX binaries are currently maintained as a community effort, so feel free to join the effort to make the download more complete. If you are interested, visit the AIX section of the SVNbinaries project on openCollabNet. The SVNbinaries project is also where you can find more information on the AIX binaries, like the build instructions and the README. Lastly, the SVNbinaries project is where you can submit feedback and requests, and even get community support.

On Friday we refreshed the Subversion 1.5 pre-release binaries of the Merge Tracking Early Adopter Program. If you participate in this beta program, please update your binaries to this latest version. These binaries are built using revision 27527 from October 31st and include fixes to some of the bugs reported by participants of the Merge Tracking Early Adopter Program.

Please note: The latest Subversion client will update a working copy to the new 1.5 format when it writes to it. Once this happens, you can no longer use a 1.4 client on the same working copy. So, make sure you do not use the new client on a production working copy; use separate working copies for Subversion 1.5 testing.

If you are not testing Subversion 1.5 yet, you can start doing so today. The Subversion developers rely heavily on users to test new versions and the need for testing is now. Subversion 1.5 development is close to the point where the committers will branch the code to a release branch. The more testing we do now, the more stable the release candidate will be, which reduces the time the Subversion developers will soak the code.

Next to testing, another goal of the Merge Tracking Early Adopter program is to give you early access to Subversion 1.5 so you can prepare your organization. With merge tracking coming, many organizations will want to look at their branching policies and optimize to benefit more from parallel development on multiple branches. If you haven’t attended our webinars on this topic, you can view the replays:

• Branching and Merging Strategies for Subversion 1.5
• Advanced Merge Tracking & Branching with Subversion

To participate in the beta, go to the Merge Tracking Early Adopter Program on openCollabNet. Here’s what you can find there:

• Links to Subversion's merge tracking design documents.
• Subversion 1.5 pre-release binaries that include the new merge tracking features.
• A sample Subversion repository that includes merge tracking history.
• Previews of  CollabNet’s new GUI clients for Eclipse (merge management and change set merge).
• Extras: ViewVC and Python bindings.
• The svnmerge.py migration script (to migrate svnmerge.py merge history to SVN 1.5).
• A forum where you can discuss the pre-release software with Subversion committers from CollabNet and with others. Report bugs in this forum.

Join us, help the community ensure a rock-solid Subversion 1.5 release, get your organization ready and see what is coming for Eclipse integration.

Hopefully you have already read my post from last week, Subversion merge made easy.  In that post, I linked to information on the new CollabNet Merge client that we are building for Subversion 1.5.  There has been a lot of good feedback from users who have downloaded and tried that client.

This week, we are introducing a preview of an extension to the merge client that allows you to perform merges based on change sets.  With this extension to the merge client, users of CollabNet Enterprise Edition's Project Tracker can perform merges by specifying Project Tracker artifacts as the input to the merge process instead of having to specify a list of revisions.  This is a really easy way to perform certain types of merges and can lead to some interesting new workflows and business processes.

If you have already installed the merge client, you can just visit the same installation site and grab the change set extension.  I have also written an overview of the client that has some more details and screenshots.  Click here for the overview of the change set extension.

While you will need Subversion 1.5 on your server to get the full benefits of merge tracking, the bulk of the features of this change set extension can be used today with your version of CollabNet Enterprise Edition.  So give it a try and let us know what you think.

Subversion 1.4.5 was released today.  You can download the updated CollabNet Subversion binaries immediately.

Subversion 1.4.5 contains a fix for a security exploit on Windows clients. This exploit was discovered and reported by researchers at the Colorado Research Institute for Security and Privacy.

The only change from Subversion 1.4.4 is the patch for this security exploit.  Since the exploit only affects Windows clients, we decided to only release CollabNet Subversion 1.4.5 packages for Windows. There is no point for someone who is already running 1.4.4 on any other operating system to update to 1.4.5.

I am not going to give a lot of details about the exploit, you can find more information at various security reporting sites, such as CVE.  I will say that it was a legitimate exposure that made it possible for the Subversion client to write files outside the normal working copy.  That being said, there are a couple of points to make:

1. Creating the exploit requires commit access to the repository.  If you can trust the people who have write access to the repository, then you do not have too much to be concerned about. The keyword in that sentence is "trust". If you are checking out from a repository you cannot completely trust, such as on a public hosting service, then be careful and update to 1.4.5 first.
2. While the exploit itself is pretty easy to produce, it is also pretty difficult to use it in a way that would cause harm.
3. You can only create the exploit from a non-Windows platform.
4. There is nothing terribly secretive about the exploit.  If you send commit emails, or even just browse your repository using svn ls, this exploit would stand out as not normal.

If you are running a Subversion client on Windows, this would include the command line client as well as any graphical client such as TortoiseSVN or Subclipse, then you should definitely go ahead and install this version of Subversion.  I would recommend that users of earlier versions such as 1.3.2 or 1.2.3 also install this update immediately. The Subversion 1.4.5 client can talk to any 1.x version of the server, so there is no reason not to update your client (for compatibility: if you have the command line and a GUI client, update them both).

Subversion servers are not affected by this exploit.  That being said, a Windows server that uses the Subversion client in scripts would still be vulnerable and should be updated to 1.4.5.

Here on openCollabNet we publish a graph that shows the adoption of Subversion on public Apache servers (actually: only those servers that report their mod_dav_svn module, Subversion). The raw data is published monthly by the Canadian security and on-line services consulting company E-Soft.

Last month Subversion reached 150,000 servers that report their Subversion module and the growth is spectacular. In August 2006 E-Soft reported 46,000 servers, a year over year growth of over 3x !!! From 2005 to 2006: same story, from 15,000 to 46,000.

The number only reflects a subset of the Subversion servers out there. There are lots of Apache servers that do not report their modules (I understand it is practice to no longer do so for security reasons). And then there are the instances of public Subversion servers that run svnserve and many more servers behind firewalls. So, the report shows the trend of the adoption of Subversion, the actual number is much higher.

Another interesting report to look at is from CIA.vc (not the government). This report covers commit messages of over 1,000 open source projects. Subversion blows all other systems away and it is clear that it has overtaken CVS by a stretch, at least according to this report.

How many developers using Subversion does this translate into? Of course it is impossible to give an absolute number but if you take an average of 5 developers on each of these servers that E-Soft reports, make an adjustment for other public servers, add some hard data on really big projects that we know about (like the Apache project), add the number of developers using Subversion as part of CollabNet’s platforms (we have hard data on that of course), add hosting services and make an estimate of corporate use, then it is fair to say that well over 2 million developers now use Subversion.

Subversion is unstoppable and certainly one of the most successful open source projects.

The last few weeks we blogged a lot about the Merge Tracking feature in Subversion 1.5.  Of course there are several other great new features coming. Let’s look at what else is new.

The Subversion 1.5 release notes (which are not final of course) mention these new features for 1.5:

• Merge Tracking
• Sparse checkouts
• WebDAV transparent write-through proxy
• Cyrus SASL support for ra_svn and svnserve
• Copy/move improvements: peg revisions, 'svn mv file1 file2; svn mv file2 file3', 'svn cp *.c dir'
• Cancellation improvements
• Changelist support
• FSFS sharding
• Command-line client improvements
• JavaHL bindings improvements
• Many improved APIs

If you are new to this blog and want to find out more about Merge Tracking, check out our Merge Tracking Early Adopter Program. Over the next few weeks we’ll blog about some of the other new Subversion features. Not about everything though, other people are blogging about 1.5 as well and we’ll link to them. For example: Malcolm Rowe blogged about mod_dav_svn improvements, tree-structured FSFS repositories and backing up FSFS repositories, Subversion 1.5 style.

In this post we’ll talk about sparse directories.

Sparse Directories

When you first checkout a Subversion repository, or a directory within that repository, you get the whole directory with everything underneath it. In large projects that can be a problem because the files are copied over the network and that can take some time. This is very contrary to how Subversion subsequently sends small deltas over the network with minimal use of network resources. Also, do you want all these files cluttering your disk?

Subversion 1.5 introduces Sparse Directories, giving you more control over what to checkout and how svn update works. You can read the specs here. But I don't learn from reading, I need to play. So let's play (but let’s be mindful of the fact that SVN 1.5 is not feature complete yet).

I started with downloading the Subversion 1.5 pre-release binaries from the Merge Tracking Early Adopter Program and setup a repository:

• Download the binaries (Windows in my case).
• Copy .exe and .dll files to c:\svn and add c:\svn to %PATH%.
• Create repository (svnadmin create repo) at c:\svn (repository is c:\svn\repo).
  Download the repository dump file that comes with the Merge Tracking beta.
• Load the dumpfile (svnadmin load c:\svn\repo < c:\svn\mergetracking.dump).
• Create directory for working copy.
• Checkout the repository (svn checkout file:///c:/svn/repo/trunk)

The main directory of the trunk of the repository contains one file and a few sub-directories:

index.html
about
jobs
news
products
support

Suppose I'm another developer (I mimicked that with working copy wc2) and I have no need for the subdirectories. With current releases of SVN, I can use the -N switch (for: non-recursive) to checkout only the main directory of the trunk and not the sub-directories:

I now have the topmost directory of trunk and the file in it, but not the sub-directories. For a big repository, this will reduce the amount of time for the checkout, and keep your working copy cleaner and subsequent updates will only pull in files added to the directory you checked out. But –N is all the control you have.

SVN 1.5 will be more flexible by making the -N switch redundant and replacing it if for a --depth option. According to the spec, the possible values for --depth are:

• --depth=empty: Updates will not pull in any files or subdirectories not already present.
• --depth=files: Updates will pull in any files not already present, but not subdirectories.
• --depth=immediates:  Updates will pull in any files or subdirectories not already present; the subdirectories will have depth=empty.
• --depth=infinity:  Updates will pull in any files or subdirectories not already present; the subdirectories will have depth=infinity.  Equivalent to today's default update behavior.

Now I am developer number 3 with wc3 as working copy. Let’s checkout the repository with -–depth=empty:

As you probably know, Subversion 1.4.4 was recently released.  I wanted to let you know that the CollabNet Subversion team is hard at work putting together our packages for 1.4.4.  We will release them in a staged order: Linux first, Solaris second and Windows third.  Most of the time and effort in our release process is spent in QA and validation and the reason we do the Linux and Solaris packages first is that we can get those versions in the hands of our QA team the quickest.  Eventually, I plan on making the order Linux, Windows, Solaris, as there are more Windows than Solaris users who are seeking the packages.

The Linux package is in the final stage of our validation process and I expect it to be available on openCollabNet later this week.  The Solaris package should be available next week and Windows the following week.

It’s worth pointing out that the most significant fix in 1.4.4 is a potential (though very unlikely) repository corruption with BDB repositories.  Since CollabNet recommends FSFS and CollabNet Subversion comes pre-configured with that back-end, this BDB fix does not affect CollabNet Subversion users.

We had a really nice addition to the Subversion merge tracking feature committed to trunk last week.  Hyrum Wright is a student participating in the Google Summer of Code program.  He has signed up to provide "Merge Auditing" features for merge tracking.  You can see some details on what this means in the functional specifications, but essentially it is about adding intelligence and awareness of the merge tracking information to the svn log and blame output.  In the merge tracking planning, this has been slated as a post-1.5 feature.  It is a feature everyone really wants to see in the code-base, but it was just felt that shipping the release and the core functionality had to be the priority.

Anyway, in this case it appears we will be able to have our cake and eat it too.  Hyrum, whom I should add is already a full Subversion committer, has made great progress on adding this support to the svn log command and has committed those changes to trunk.  Additionally, it turns out that the sample repository we created for our Merge Tracking Early Adopter program really helped to work out the kinks in this feature.  Since we had a nicely documented sample repository, and matching graphic, that Hyrum could refer to, it made it easier for him to refine the feature and get it working properly.

The above picture is the history of our sample repository. If you take a close look, the r14 commit to trunk is an interesting example where this feature comes into play.  This commit is a merge from a branch, and the merge also contains additional merges from another branch.  If I run this command (note the new -g option):

svn log -g -r 14 $REPOS/trunk

Here is the new output:

------------------------------------------------------------------------
r14 | merger | 2007-05-30 15:48:11 -0400 (Wed, 30 May 2007) | 3 lines

Merge branch b - product roadmap and update about page

Command executed: svn merge $REPOS/branches/b
------------------------------------------------------------------------
r13 | buser | 2007-05-30 15:46:48 -0400 (Wed, 30 May 2007) | 1 line
Result of a merge from: r14

Update info about our company
------------------------------------------------------------------------
r12 | merger | 2007-05-30 15:45:19 -0400 (Wed, 30 May 2007) | 3 lines
Result of a merge from: r14

Merge branch a - product roadmap

Command executed: svn merge $REPOS/branches/a
------------------------------------------------------------------------
r11 | auser | 2007-05-30 15:43:00 -0400 (Wed, 30 May 2007) | 1 line
Result of a merge from: r14, r12

Add product roadmap
------------------------------------------------------------------------

Note how it includes information on the revisions that were merged in r14, and additionally how one of those revisions was the result of another merge.  Graphical clients like our CollabNet Desktop - Eclipse Edition and TortoiseSVN should be able to do really useful and interesting presentations of this information in their UI.

This is fantastic work Hyrum.  Keep it up.  I cannot wait to see the blame implementation come together.

Those of you who diligently watch your e-mail Inbox for those little blessings that come via announce@subversion.tigris.org recently got a pleasant surprise, though perhaps not the one you'd been wishing for. It's been nearly five months since Subversion's last release — nine months since the introduction of the 1.4 version line. "Where's the next big Subversion release?" "What's taking so long!?" "I want Merge Tracking, and I want it yesterday!"

Don't worry, Subversion 1.5 remains on schedule. Merge Tracking development is still ongoing, as is support for sparse directories and a number of other improvements and features. Those are, of course, in addition to all of the other goodies that 1.5 promises to bring which are already completed. But along the way of developing Subversion 1.5, we found enough important issues in 1.4.3 to justify another patch release on this line.

Subversion 1.4.4 delivers a number of bug fixes for various issues, including (but not limited to):

• an extremely rare directory property dataloss bug which, for BDB-backed repositories, also unfortunately results in repository corruption
• a race condition when changing revision properties in FSFS-backed repositories
• a low-risk security flaw in the 'svn prop* --revprop' subcommands
• problems with 'svn diff' when writing large diff hunks to the Windows console
• a path sorting bug in the output of 'svnadmin dump' for non-ASCII paths which can cause invalid dumpfile generation
• a hang bug triggered during character translation

Now, some of those items look sorta scary. Data loss, repository corruption, race conditions — that's the stuff a technologist's nightmares are made of! But without downplaying the significance of the fixes to those problems, allow me to assure you that the instances of them have thus far been extremely rare. Still, you are encouraged (as always) to upgrade to this latest release of Subversion.  You can see the full set of changes made in 1.4.4 in the Subversion CHANGES file.

And if you're one of those folks dying to get your hands on Merge Tracking functionality, let me encourage you to join the openCollabNet Merge Tracking Early Adopter Program. The more feedback the Subversion developers get on their work, the better — and more timely — the feature will be overall.

I often talk to developers at large companies that are on a version control system dictated from the top but disliked by developers and administrators. The legacy system is too hard to use, not a good fit for distributed development and often too difficult and expensive to deploy. What happens is that developers start to implement their own Subversion servers for their teams or departments. CIOs and VPs of development see this happen all over the company and wonder what to do: continue to enforce a system that does not work for the company or jump on the Subversion train? Before that can happen, they need to be convinced that Subversion is scalable, secure and ready for the enterprise and they want to be convinced by more than their own people; they look at what other companies do, where the industry as a whole is moving and what external experts have to say.

If you are one of those people working for a company that uses a legacy system that you would like to see replaced with Subversion, here is some good help for you: Forrester just released the report “The Forrester Wave™: Software Change and Configuration Management, Q2 2007”, which cites Subversion as the sole leader in standalone SCM.

The way these things work, I am actually not allowed to quote much of the report in this blog. I guess Forrester wants you to read the actual report and ensure that nobody places things out of context. Fair enough, they did the hard work and objectivity is important. If you want to read this independent report, you can get a copy from our web site.

There are a couple of things I can share in this blog. For instance: “The Forrester Wave™, which is a graphical representation of Forrester's call on the market. As you can see, for standalone SCM Subversion is indeed the sole leader:

I can also share what Carey Schwaber wrote about Subversion. Ms. Schwaber is Senior Analyst at Forrester Research and her research area is Application Development with a special focus on SCM tools:

"Subversion’s strengths are scalability, administration, and geographical distribution. Subversion’s ability to scale to meet enterprise needs is well established, with single instances managing 7,500 users... Subversion is also easy to implement and administer: Subversion customer references reported initial implementation times of less than a month and administrator-to-user ratios of better than 1:1,000".

So, if you need help convincing your management that Subversion is ready for your company, send them to http://www.collab.net/forrester_wave_report.

              Get this great news out, Digg this story. 

The Subversion project is very active in publishing regular releases but does not officially endorse or maintain any binary packages of the Subversion software. Instead, you can download binaries from volunteers, including CollabNet which provides Subversion binaries for Windows, Red Hat Linux and Solaris. The advantage of this volunteer system is that Subversion is available for many platforms but the disadvantage is that for certain platforms the availability of Subversion binaries has been spotty or has not stayed in sync with Subversion releases.

On June 1st we will start a new community project on openCollabNet: SVNbinaries. The goal of this project is to create binaries for a wide range of platforms and ensure continuity through the support of a community rather than individuals. Next to creating Subversion binaries we will work on improving build scripts and we'll ensure that bindings for many languages are available for download.

We know that many people already make binaries available and it is not at all our goal to “compete” with them; being a good citizen of the global Subversion community is very important to us. The project will not be the one place for the download of Subversion binaries, we’re happy to link to other places where you can find them. The goal is to create a community that improves build scripts and ensures that a wide variety of binaries and bindings is available on a continuous basis. In fact, people who already make binaries available are warmly invited to participate in this project so others can join them to improve their build scripts, ensure bindings are available and make derivatives for different dependencies.

So, what binaries and bindings are we specifically looking for? The community should drive this. People will step forward with their work while others will ask for something. If a need is common across the Subversion community, we will find people to fill it.  CollabNet will seeded the project though; Jeremy will contribute the Mac OS X client binary he recently created.

The community is not starting with a lot of rules around participation; rules will be created over time by the community itself. We’re starting with a simple process modeled after common practices in the open source world: you contribute something, other people evaluate it and if it is deemed good and you commit to active participation then you can become a full or partial committer in the project.

If you would like to contribute your binaries and build scripts or help improve other people’s work, send us an email. You can find the project at http://svnbinaries.open.collab.net. It will go live "officially" on June 1st.
 

Jeremy Whitlock, Mark Phippard and Guido Haarmans

The Subversion open source project has earned a reputation for paying close attention to its processes, and doing its best to find that "sweet spot" where as much information as possible is harvested from its contributors without frustrating them with overbearing rules and regulations. One area where this plays out is in the composition of log messages attached to commits and would-be commits (patches). The project has some pretty picky guidelines about the content and format of its log messages. These guidelines (which can be found at http://subversion.tigris.org/hacking.html#log-messages) are among the lengthiest bits of Subversion process documentation to be found. They require, among other things, documentation of the change made at the granularity of a single function (or symbol).

Why? Why not just use a short one-liner log message that points folks to an issue tracker artifact or an archived email thread where the full history of the background of the change is more likely to be found? Is this just an old habit from the Subversion community's CVS days that didn't die, or are there benefits?

These questions were asked of me recently, and I try here to answer them.

Recently, our founder and CTO Brian Behlendorf decided to step back a bit. He is still around but turned over the CTO cubicle to me. Quite coincidentally, but pretty much at the same time, CollabNet purchased SourceForge Enterprise Edition from VA Software, bringing the world's two premier commercial web-hosted software collaboration environments under a single roof. If all that doesn't call for a little blogging, I don't quite know what does!

So, what shall we talk about? The past? Next steps? New beginnings? How about "all of the above"?

By this point in time, I think no one can doubt that the open source software development community has accomplished some amazing things, things in some cases that the enterprise community has attempted repeatedly and failed at. Such singular achievements come to mind as sendmail and BIND, the rolling collective stewardship of the UNIX family of operating systems, the famous "LAMP stack," or any number of other dramatic achievements. But at the same time, there's no question but that the open source process has some liabilities that are really worrisome to the enterprise -- you know the list: imprecise schedules, false-start and abandoned projects, and a tendency to ignore less "sexy" details like quality, localization, and customer support. The best open-source projects can equal or better the best enterprises in all these matters, but then there are all those distressing not-so-best projects.

There's some kind of magic in the open source community process, but it needs some taming. CollabNet was founded (thanks, Brian!) to capture the magic of the open source process, civilize it just a bit, and bring it to the enterprise. They (before my time) provided a set of tools proven in the open-source arena, but didn't hesitate to help the community produce better replacements where necessary, such as by sponsorship of Subversion development to replace CVS: the magic's not in the tools, but in the processes that co-evolved with them. CollabNet added features like rich security and authorization systems, that are crucial to enterprise use but uninteresting (if not down-right antithetical) to the open-source community. Brian also brought with him, from experiences in the Apache community and elsewhere, both wisdom and contacts at the heart of the communitarian open-source magic.

Since I joined the company in 2002, we have added world-class hosting and support services, scalability, enterprise-focused features like project management and reporting, and have opened the product to partner and customer integrations through APIs. By this time, as well, surely no one has missed the significance of SourceForge. Through its public face sourceforge.net (as well as its several other properties), VA Software has served and fostered the open-source community immeasurably. Through their commercial offering, SourceForge Enterprise Edition, they've distilled that open-source magic into their own commercially successful brew. But VA Software found their business growing in other directions as well, into online media, and have discovered a need to focus their energies there.

Transferring SFEE to a more suitable home became very attractive. CollabNet is a great place for SFEE, and we're delighted to bring over this complete team, well experienced in our core field, and their solid and innovative product. So where do we go from here? Hey, give me a while to work out the details of a combined product roadmap; I'll get back to you on that. But I'm "new" around here, and we're just getting started!

Do you live in the Bay Area, or are you going to JavaOne?

CollabNet is organizing a success party for Subversion. Join members of the Subversion team at CollabNet’s headquarters in Brisbane (just south of San Francisco). It will be an informal party but we’ll have some Subversion related things to show as well, like a preview of the upcoming capabilities of Subversion 1.5.

The party will take place on May 10th starting at 4pm with cake and champagne. After that we will have a networking reception where you can meet with people like Brian Behlendorf (CollabNet and Apache co-founder), Subversion committers and many others from the Subversion community.

Find out more and register at http://www.collab.net/subversion_party_RSVP/.

I see a lot of questions asked about "What is the recommended repository layout?", "What does trunk mean?", or: "What is the significance of trunk?". This post will try to answer those questions and more.

A Subversion repository implements the metaphor of a versioned filesystem. The repository is just a filesystem with folders and files. It so happens that modifications to this filesystem are versioned and there are implementation enhancements like "cheap" copies that make certain operations less expensive than they are in a traditional filesystem, but the repository itself still behaves like a filesystem: there are no special folders or names and Subversion itself has no knowledge of trunk or branches, they are just folders within the filesystem. It is up to you as the user to give those folders names and structure that are meaningful to you.

That said, there are several common layouts that have been adopted by the community as best practices and therefore one could think of these as recommendations. If your repository is accessible to the public, following these conventions might make it easier for users that have accessed other Subversion repositories to find what they are looking for.

There are two commonly used layouts:

trunk
branches
tags

This first layout is the best option for a repository that contains a single project or a set of projects that are tightly related to each other. This layout is useful because it is simple to branch or tag the entire project or a set of projects with a single command:

svn copy url://repos/trunk url://repos/tags/tagname -m "Create tagname"

This is probably the most commonly used repository layout and is used by many open source projects, like Subversion itself and Subclipse. This is the layout that most hosting sites like Tigris.org, SourceForge.net and Google Code follow as each project at these sites is given its own repository.

The next layout is the best option for a repository that contains unrelated or loosely related projects.

ProjectA
   trunk
   branches
   tags
ProjectB
   trunk
   branches
   tags

In this layout, each project receives a top-level folder and then the trunk/branches/tags folders are created beneath it. This is really the same layout as the first layout, it is just that instead of putting each project in its own repository, they are all in a single repository. The Apache Software Foundation uses this layout for their repository which contains all of their projects in one single repository.

With this layout, each project has its own branches and tags and it is easy to create them for the files in that project using one command, similar to the one previously shown:

svn copy url://repos/ProjectA/trunk url://repos/ProjectA/tags/tagname -m "Create tagname"

What you cannot easily do in this layout is create a branch or tag that contains files from both ProjectA and ProjectB.  You can still do it, but it requires multiple commands and you also have to decide if you are going to make a special folder for the branches and tags that involve multiple projects. If you are going to need to do this a lot, you might want to consider the first layout.

As for the names of the folders within the repository, again: they are just a convention. They have no special meaning to Subversion.

"trunk" is supposed to signify the main development line for the project. You could call this "main" or "mainline" or "production" or whatever you like.

"branches" is obviously supposed to be a place to create branches. People use branches for a lot of purposes. You might want to separate your release or maintenance branches from your feature branches or your customer modification branches etc. In this case, you could create a layer of folders beneath branches, or just create multiple branch folders at the top-level.

"tags" are not treated as special by Subversion either. They are a convention, perhaps enforced by hook script or authz rules, that indicate you are creating a point in time snapshot. Typically the difference between tags and branches is that the former are not modified once they are created. You might call your tag folders "releases" or "snapshots" or "baselines" or whatever term you prefer.

Remember, the significance of the name is for your benefit, not for Subversion. Finally, the architecture of Subversion, with its global revision number can often make the need for tags unnecessary. I do not think there is any reason to create tags just for the sake of creating them. If you find a need to recreate the software at a specific point in time, you can always do so by using svn log to determine the relevant revision number. Tags are best when there are "external" consumers of the repository. Maybe it is a QA/Release team that needs to perform builds, maybe it is an internal development team that wants to use releases of your code in another product, or maybe it is literally external users or customers who need to grab release snapshots from your repository. In these scenarios, creating tags is both a convenient way to be sure they get the right code, as well as a good communication mechanism to indicate the presence of release snapshots.

Hopefully this post clarifies some of these issues for you and makes it easier for you to understand how Subversion works.

I would like to finish by pointing out that a Subversion repository layout can be changed. You can always reorganize and restructure your layout after the fact. At worst, it just might create some short term pain as users adjust their working copies. It is not like you need to start over though. Just change names, move folders or do whatever to get the filesystem looking the way you want it.

Usually compiling JavaHL is pretty simple: just follow the directions mentioned in the source code. Not on OS X though, there is an anomaly on OS X when running "make javahl" or "make install-javahl". When you run these make targets on OS X, you get output like this:

ld: multiple definitions of symbol ___divdi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_divdi3.o) private external definition of 
___divdi3 in section (__TEXT,__text)
/usr/lib/libgcc_s.10.4.dylib(_divdi3_s.o) definition of ___divdi3
ld: multiple definitions of symbol ___udivdi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_udivdi3.o) private external definition of 
__udivdi3 in section (__TEXT,__text)
/usr/lib/libgcc_s.10.4.dylib(_udivdi3_s.o) definition of ___udivdi3
ld: multiple definitions of symbol ___umoddi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_umoddi3.o) private external definition of
___umoddi3 in section (__TEXT,__text)
/usr/lib/libgcc_s.10.4.dylib(_umoddi3_s.o) definition of ___umoddi3
/usr/bin/libtool: internal link edit command failed
make: *** [subversion/bindings/java/javahl/native/libsvnjavahl-1.la] Error 1

After digging around, I finally joined the #fink irc channel on irc.freenode.net and started asking questions (I heard they had a working script to compile the JavaHL bindings.) After talking to a few people in #fink, they passed me this nice little snippet that fixed the problem:

perl -pi -e "s/-all_load//g" libtool

The above Perl call removes the "-all_load" flag from libtool to work around a libtool issue on the Mac. Going into deeper detail is really a libtool matter and I'll omit that here but let me give you a little cheat sheet for building the JavaHL bindings from scratch. Here are the brief steps:

1. Download Subversion source.
2. Change directory to where you downloaded the Subversion source.
3. Run "./autogen.sh".     
4. Run "./configure <your_flags>". 
5. Run "make". 
6. Run "perl -pi -e  "s/-all_load//g" libtool". 
7. Run "make javahl".     
8. Run "make install-javahl".

If you follow the steps above, you'll have a working JavaHL installation on your OS X system.  Enjoy.

On Wednesday CM Crossroads and CollabNet hosted a webinar: Subversion in the Enterprise, presented by C. Michael Pilato and Bob Jenkins from CollabNet plus Terrence Cordes, SCM manager at Reuters. Terry gave some great insights into deploying Subversion across global teams; I’ll post a link to a recording of this webinar here soon. Because the presenters only got to a few of the questions that were asked, we will answer some of the remaining ones in this blog over the next few weeks. Here is the first one, asked by a couple of people:

Do you recommend multiple repositories for distributed teams due to WAN performance? 

Subversion itself does not support synchronized repositories that are concurrently used for read and write. Subversion uses one central server. When it was designed, the WAN was kept in mind and networking with low bandwidth requirements is built into the system.

Subversion’s working copy model means that the developer works on his or her code without needing to be connected to the server. You only need a connection with the server in a few cases, for instance for a commit or when updating your local working copy with changes from the repository. When data is sent back and forth, only differences are sent.

Mike Pilato actually touched on this during the webinar. If you make a small change to a large file and commit that change, only the change is sent across the network, not the entire file. This minimizes band-width requirements. Subversion only needs to send the entire files across the wire the first time a developer checks out the repository.

The conclusion is that WAN performance is not an issue when considering Subversion, assuming your network is reliable.

Subversion does have some support for multiple repositories. With version 1.4 svnsync was introduced. This utility lets you replicate your repositories into any number of read-only copies. There are several usage models for this, with back-ups being the most common.

But there are other usages as well. For example, at EclipseCon I met some people from the Philippines who were asking about using multiple repositories to get around network downtime (we’ve all heard about the recent big internet outage in Asia). Their development team is in Los Angeles but build and test happens in the Philippines. This company can set up a main repository with read-write access in the US and use svnsync to make a remote copy for the build and test team. Should the international network go down, they can access the local read-only copy to make a build.

You can find out more about svnsync by typing “svnsync help” at the command prompt or check the online version of Version Control with Subversion. The authors are updating this book for release 1.4 and have a chapter on svnsync (I cannot give you the exact url of the svnsync chapter, due to daily builds the url changes all the time)

If you want to use Subversion and really need multiple read-write repositories, there is a solution: svk (its primary author is Chia-liang Kao). svk is a decentralized version control system built on top of Subversion. It supports things like repository mirroring and disconnected operation. Some people will prefer this but before you choose a distributed repository solution make sure you really need it. It does have some advantages for developers if they are often working disconnected from the network, for example: like Subversion they can work disconnected but additionally they can commit to a local repository. However, it can come at the cost of higher administration overhead, fatter bandwidth requirements and more server infrastructure. Subversion’s centralized model is easier to deploy and maintain and, if you don’t need a distributed model, will have lower cost of ownership.

People have asked CollabNet about the implications of the changes to daylight saving time to Subversion. This year DST will start a few weeks earlier in many countries and older operating systems are not aware of the change. The Subversion Development Team has posted a message on Tigris.org to answer the question. CollabNet customers on a hosted Subversion solution do not need to take any action, we will take care of patching the systems.

OpenCollabNet has been live for over 4 months now and has drawn quite a crowd. We have over 3,000 members and 60,000 unique visitors. What we were missing was a blog about Subversion. Here it is.

I have invited a number of my colleagues to blog here and we will focus on technical topics, especially about deploying Subversion for globally distributed development and large teams. Blog posts will come from our Subversion committers who work in the open source community, people like C. Michael Pilato, and you’ll see Mark Phippard who recently joined us; he is the lead on the Subclipse project. And some of our technical consultants can’t wait to share experiences about their work at customers who are doing large-scale deployments of Subversion.

If you have ideas about what you want us to blog about,