It is an exciting time for Subversion as its adoption continues at a dizzying pace in enterprises. I'm out there helping that adoption so I'm a bit late in posting the questions and answers I promised around the three basic branching strategies that I covered in the last two webinars in which I presented (Branching and Merging Strategies for Subversion 1.5 and Advanced Merge Tracking and Branching with Subversion 1.5). Hopefully these will be useful to many of you.

First, a quick reminder on what the three branching strategies were:

1. The unstable trunk which mimics the way that Subversion itself is developed. In this model, development is done on the trunk and a release branch is created around the time of feature completion with the formal promotion process carried out on that branch.

2. The stable trunk where development is done on system version branches and the promotion process is also conducted on that branch. The trunk is the branch point where the production releases are merged in and parallel development efforts are branched out.

3. The agile release strategy where development is done on individual feature branches and a release branch is created late in the process with the feature branches merged to it that will define that release. The formal promotion process is conducted on the release branch and the production version merged to the trunk as well as to all remaining active feature branches.

So on to the questions, first general branching questions:

The following instructions on how to change the SourceForge Enterprise Edition Download to function with Subversion 1.5-dev are at your own risk and not supported by CollabNet. Subversion 1.5 is not released yet and I don’t recommend that you tinker around with the SFEE Download image that you use for development.

If you are still eager to get Subversion 1.5-dev on your SFEE Download machine: Read on!

Why do this?

I was really interested in testing the new features of Subversion 1.5, like merge tracking, sparse directories and sharding. I also love to work with SourceForge Enterprise Edition, which I use for my projects. The downloadable edition of SourceForge Enterprise Edition ships with Subversion 1.4.3 and I decided to "pimp" my VMware image to support Subversion 1.5-dev.

Yum is your friend

The preconfigured SFEE 4.4 Download VMware image does not have a graphical user interface, like KDE, or a browser, and it does not ship with development tools like gcc. This decision was made intentionally. If you use SFEE 4.4 with the preconfigured Subversion 1.4.3 you only have to log into the VMware image once to do the initial configuration. After that you never have to touch the system again (which is a good thing). However, if you plan to upgrade SFEE 4.4 to Subversion 1.5-dev, you will need lots of software that does not ship with the image (it is normally not needed and would only result in longer download times).

The first step I would recommend is to upgrade the package manager of the underlying operating system (Cent OS 4.3) to let you access the software repository of rpmforge: http://wiki.centos.org/Repositories/RPMForge

After that, you can use yum to get virtually every software package you like on your machine. I started to install KDE, Eclipse, gcc and lots of other tools to facilitate the porting process. To proceed, you will need at least the C and C++ compilers, the python developer package, autoconf and libtool.

Backup everything

Before proceeding with the next step, you should save everything that is worth saving. As mentioned above, the upgrade process is risky and must not be used for any production system. Make sure to save a copy of apache's httpd.conf

Checking out Subversion 1.5-dev

The Subversion 1.5 binaries from CollabNet are built for Apache 2.2. SFEE 4.4 is built with Apache 2.0.52, so you have to build Subversion yourself. Don't worry, I had never done this before and only read the INSTALL file of Subversion once to understand how it works. You can checkout Subversion by typing "svn checkout http://svn.collab.net/repos/svn/"

Removing the old stuff

You have to upgrade the apr libraries on the VM-ware image to build Subversion 1.5-dev. You can easily get rid of the old ones by typing "yum erase apr". On the SFEE Download, this will remove your Apache as well as Subversion and all Subversion related Apache modules (due to package dependencies on Cent OS 4.3). Your SFEE will be temporarily broken after this step. Please ensure that you checked out the Subversion's source code before doing this step.

After having removed the old libraries, you may type "yum install httpd-devel" to install Apache and its header files again. Copy the saved httpd.conf file over the new one to preserve SFEE's apache configuration. Do not try to start Apache again, the Subversion modules are still missing and SFEE's apache configuration relies on them.

Building Subversion

This is maybe the hardest step, but if you follow the instructions in the INSTALL file in the top level directory of Subversion's own repository (you've just checked it out), you will have no problems. You have to download  and install the newest versions of libapr 0.9.x and libapr 0.9.x and libneon or libserf (do not use the Cent OS 4.3 standard packages, they are too old). Optionally, you may download OpenSSL and libasl as well. The INSTALL file contains all information how to do this. For libz, you may use the version that yum provides you.

Last but not least, Subversion 1.5-dev requires SQLite development packages. You may install them by typing "yum install sqlite-devel". However, sqlite occasionally causes problems with some versions of yum. If yum freezes after this step, take a look at this forum post or make sure that you install a newer version of python-sqlite before.

If you plan to use SFEE to browse through your repositories, you will need the python bindings as well, so take a look at subversion/bindings/swig/INSTALL as well. You will have to install SWIG, which is explained in the INSTALL file.

After that, you can start to build and install Subversion 1.5 and the python bindings:
./autogen.sh
./configure --prefix="/usr/" --enable-dso --with-ssl --with-apxs=/usr/sbin/apxs
make
make install
make swig-py
make install-swig-py
echo /usr/lib/svn-python > /usr/lib/python-2.3/site-packages/subversion.pth

Congratulations

If you successfully followed the above instructions, the last thing you need to do is restarting the apache webserver: "/etc/init.d/httpd restart". Afterwards, your SFEE 4.4 should run with Subversion 1.5.0-dev and it will be easy to upgrade Subversion 1.5-dev to new revisions: simply repeat the last steps after an svn update of the working copy where you keep the Subversion code.

Enjoy!

Feedback appreciated

I am totally aware of the fact that this description still requires a lot of work for you and only covers the IMHO most important points in the upgrade process. Of course I can go into detail, but first I like to find out whether there is any interest in having Subversion 1.5-dev on SFEE 4.4 at all. If you have questions regarding an upgrade step or have a better way to do it, please tell me.

There is also another possibility to upgrade on Subversion 1.5-dev: Upgrade the apache application server to version 2.2, rewrite the SFEE-specific httpd.conf and its dependent files and install CollabNet's pre-built Subversion 1.5 binaries from the early adapter program . Please tell me about your experiences with that approach or whether you are interested in getting a description how that would work.

Over the past months we blogged a lot about Subversion 1.5 and its new capabilities. People often ask: “Can you show us the changes from 1.4.x to 1.5 on the command line?”

I’ve created a PDF that answers this question by analyzing the built-in documentation of Subversion 1.5-dev and comparing it to the documentation of Subversion 1.4.x. The changes made to Subversion's  subcommands reflect most of the new features. 

The results of my investigation are in the Merge Tracking Early Adopter Program (the SVN 1.5 beta). Look for the document titled: "Subversion 1.5 Command Line Changes". All new features of Subversion 1.5-dev are highlighted in blue (when necessary, limitations of the AS400 port are mentioned as well).

I’m currently working on a document that describes and compares all new, obsolete and unchanged switches of the Subversion 1.5-dev subcommands. Please tell me what you think about the command-line-comparison approach and whether I should provide you a comparison for svnadmin, svnlook, svndumpfilter and svnsync as well.

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.

I've had the pleasure of participating in two recent webinars on the topic of branching and merging particularly in the context of the pending 1.5 release with merge tracking. The first webinar, entitled "Branching and Merging Strategies for Subversion 1.5", focused on three branch and merge models. The second, "Advanced Merge Tracking and Branching with Subversion 1.5", focused on questions from the audience of the first webinar. The intent of both was to provide some practical information on a topic that has great importance in enterprises, but isn't well covered by what's generally available around Subversion.

I wanted to post some of the questions and answers that I covered in the second webinar here in our blog. I hope that they will be useful and I encourage you to view the replays of the webinars to learn more (http://www.collab.net/webinar21 and http://www.collab.net/webinar22).