Branching and merging are two inherently related functions that are due for a long-awaited upgrade in Subversion 1.5. In this article John Ferguson Smart explains branching and merging in Subversion and shows you how these functions can scale from simple to complex as your code base evolves. He then introduces the new merge features to be introduced with Subversion 1.5, which will make tracking updates and resolving merge conflicts easier than ever in your rapidly changing code.
Subversion is a powerful, open source version control system that has rapidly grown in popularity over recent years. It is well on the way to replacing the venerable CVS as the standard open source version control system. Indeed, since the release of version 1.0 in February 2004, the number of organisations adopting Subversion has grown at an impressive rate. In a recent informal poll, Subversion scored over twice as many users as CVS (and, incidentally, many times more than any of the commercial version control solutions).
Subversion boasts many advanced features, such as atomic commits, versioned directories, good support for binary file formats, fast branching and tagging, and support for several network protocols, including HTTP. Subversion's merge features have always lacked automatic traceability, however, making it difficult to find out after the fact what code was merged, where it was merged from, and when it was merged.
Subversion version 1.5, in beta at the time of writing, brings many improvements in this area. Subversion 1.5 makes it easier to merge code from different branches and automatically keeps track of what merges have been performed. It also supports strong IDE integration with Eclipse. This article introduces merging and branching in Subversion 1.5.
Merging and branching in Subversion
Branching and merging are important elements of any version control system, and play a crucial part in any software development process. Branching strategies are many and varied, and it is important to get a clear idea of your chosen strategy right from the start of your project. Before looking at Subversion's merge features, I'll go through the common branching and merging strategies used today.
Probably the most common approach to branching involves having a main development trunk where the bulk of the development work is done. Whenever a release version is ready, a separate branch is created for this release. For example, you might create a new branch whenever you released a new version of your application for acceptance testing or into production. You might also want to create a branch for a specific, non-trivial bug fix. Meanwhile, your cutting-edge development work would continue on the main branch. This setup allows you to make maintenance bug-fixes to the production version without having to release the latest unstable version of the code.
You might also use branching to work on a major new feature or refactoring exercise that is likely to take some time, and may or may not be included in the next release. This way, work can be done in isolation, without compromising the daily builds for the rest of the application.
You will eventually want to integrate changes made in a branch back into the main development trunk. For example, you might want to apply a bug fix made in the production branch to the development branch as well. Or you might want to integrate new features into your main code base, as shown in Figure 1.
This approach is simple and robust, and suits a large number of projects. Another branching strategy, illustrated in Figure 2, involves placing only stable, production-ready code in the main trunk. Separate branches are created for development work on new versions or bug fixes When the code in a development branch is ready for release, it is merged back into the main trunk. This strategy arguably provides better support for larger teams, more complex projects, and parallel development efforts. Its downside is additional overhead in complexity and administration.
The second strategy is obviously more complex than the first, and is overkill for many projects. As in many things, the best approach is the simplest one that gets the job done.