SVN Branching and Merging
Branches allow your team to work on multiple versions of your code simultaneously. Developers can test out new features without impacting the rest of development with errors and bugs. When the new feature is stable, the branch is merged back.
In Subversion (SVN), a branch is just a name. Merging SVN branches can be time-consuming and constraining. Developers must manually resolve conflicts, which can have major implications on delivery.
Subversion Branching Strategies
The most common complaints about SVN is its tedious branching and complicated merging model. SVN branches are created as directories inside a repository. This directory structure is the core pain point with SVN branching. It costs what every developer needs more of: time.
SVN Branching Basics
SVN’s “branch” directory runs parallel to the “trunk” directory. A SVN branch copies the trunk and allows you to make changes. Relationships between branches and the branch’s relationship to the trunk is not stored easily in SVN. Development must come up with a naming scheme or create external documentation. But this Subversion branching strategy is not optimal.
As you’re working on your branch, you occasionally merge from the trunk to your branch to keep your directory up-to-date. Every time this happens, changes are copied and duplicated into your branch directory. This may or may not reflect changes other developers are making.
SVN Merging 101
When the branch is ready, you commit back to the trunk. Of course, you’re not the only one merging changes. Your version of the trunk might not reflect developers’ branches. This means conflicts, missing files, and jumbled changes riddle your branch.
Let’s look closer at this example.
The 1.0 trunk has two developers working on separate releases. As the 1.4 and 2.0 dev branches are being worked on, they will merge from the trunk to the dev branch to gather updates.
Parallel SVN development creates limited visibility into other branches. When the 1.4 dev branch merges with the trunk, it is pushed out to development. This may happen with minimal conflict, but the same cannot be said for the 2.0 dev branch.
Long-lived branches have greater risk of issues. SVN does not tell you where your branch belongs on the trunk. You have to comb through code to figure out where it belongs and what changes are missing. Tree conflicts usually occur when changes are made to the directory structure. This can happen when renaming or deleting files. Since these changes are quite common, you’re going to be searching for a while.
Since you can’t commit your changes when there is a tree conflict, you have to manually resolve each error. Even with “merge tracking,” you might not be able to figure out what changes are missing from your branch. This can have major delays to deployment. Plus, as teams get bigger, the trunk can become less stable and harder to maintain.
Streaming Past SVN Branching
It’s clear that SVN branching and merging is a problem. Helix Core offers a powerful and easy approach to branching: Streams. Developers can use Task Streams to work on a small portion of the project without impacting production or other developers.
Streams define the purpose of each branch: mainline, development, task, or release. They follow the mainline model that all changes flow toward the mainline, similar to an SVN trunk. It lets developers focus on their code — not the branch and merge. Stream Graph creates a graphical representation of branch hierarchy. This means that your team always knows what everyone is working on. And exclusive checkouts and granular permissions for Streams creates even more visibility.
This Streaming strategy solves a lot of the issues with SVN branching. In Helix Core, there is no fixed naming scheme. Helix Core uses a separate database table to track every merge. And there are many ways to trace changes across branches: revision history, time lapse views, and revision graphs.
Compare P4 commands and SVN commands.