JAW Speak

Jonathan Andrew Wolter

Subversion Parallel Multi-Branch Development And Merging

with 4 comments

Reading time: 2 – 2 minutes

As discussed in my previous post, I dislike merging-based-development, preferring Trunk Based Development instead. But, sometimes you’re stuck with a long-lived development branch, and you need to merge changes (subversion tree-conflicts and all). At the end of the post, I have several scripts I used to make this easier. Not the prettiest, but saved a lot of pain when we had major refactorings in trunk, and needed to locate and merge the changes to those files in a long lived (read: horrible) dev branch.

Imagine this scenario: Multiple streams of development, with a long-lived “3.0 dev” branch that has never reintegrated with the trunk. (Because 3.0 has new features that won’t go into production for many months).

branch-and-merge-problems-1

There are substantial dangers in this approach. This diagram only touches on the surface of the areas of risk in which a merge could fail. Solution? Trunk based development / branch by abstraction.

branch-and-merge-problems-2

Given this required scenario, I developed a few best practices and scripts for merging. The best practices involved having multiple branches checked out into different directories. And then we would find equivalent files that have moved and merge the tree-conflicts.

Scripts to assist in Subversion 3 way merging.

Custom diff3-cmd configuration setting in svn:

Bookmark and Share

Written by Jonathan

November 3rd, 2010 at 4:21 am

4 Responses to 'Subversion Parallel Multi-Branch Development And Merging'

Subscribe to comments with RSS or TrackBack to 'Subversion Parallel Multi-Branch Development And Merging'.

  1. First, I agree that branch based dev is not desirable, but occasionally necessary.

    Does Subversion support merging the trunk to the long running branch, and then when the branch work is done, merging the branch back to the Trunk? Or will it raise all sorts of conflicts because it’s confused about what changes take precedence.

    If not, then in situations like this, a DVCS will work much better. On one of our projects, we’re doing feature branches because of constraints from the client. They want to be able to say ’ship now’, and only get the features that are dev complete.

    With Mercurial, we have all the features on branches. When a feature is complete, and merged to ‘Trunk’, it is then merged out to the various features.

    When another feature finishes, and is merged to ‘Trunk’, Mercurial does a good job of resolving the conflicts.

    Also, because it tracks renames, you don’t have to do manual tracking of renamed files.

    It’s not perfect, but it certainly makes the situation much more bearable

    Mike

    3 Nov 10 at 9:27 am

  2. [...] it by manually fixing the tree conflicts (some of these scripts might help you), and mark the conflicts as [...]

  3. [...] SVN offers either merge-based development or trunk-based development. [...]

  4. Buy Litecoins With My Debit Card…

    Subversion Parallel Multi-Branch Development And Merging at JAW Speak…

Leave a Reply