Web development tips with a side of sarcasm

Merging Changes from Branches in SVN


This is a tip for TortoiseSVN Source Control and covers branching and merging.  If you don’t know what that is, read this nice help document.

We often need to try out an idea without mucking up the main line of development.  To do this we copy the code out into a “branched” version. I use these branches to manage multiple iterations of a project e.g. 2.7, 2.8, 2.9…

The problem is when you have 2.7 in production and you’re working on 2.8 in a branch, someone finds a bug in 2.7.  You fix it no problem but the question remains – how do I get those code changes into 2.8?  I could copy and paste them by hand (ek!). Or I could use TortoiseSVN to help me along.

TortoiseSVN allows you to “merge” changes from one branch of code to another.  And yes, you get control over which changes you want to include.

From now on I’ll call our copy with the changes “source” and the copy that we need the changes to be in as “destination“.

1. Check In Your Changes

Make sure your source AND destination copies are all checked in.  If it’s not in Subversion, you can’t merge it.  And, also, if it’s not in Subversion, you can’t restore it.  Be safe. Check it all in.

2. Merge a Range of Revisions

Since we’re taking changes from one branch into another, we’re going to do what’s called a “Range of Revisions” merge.

  1. Right click on the destination folder and choose TortoiseSVN > Merge.  You’ll get a dialog like this:

  2. In the next screen you’ll be able to pick the source, the revision number (or head) and the destination. For my example, were going to grab the latest (head revision) of the 2.75 branch and merge it into the local working copy of the 2.8 branch.  You just need to make sure your source and destination paths are correct and that you’re getting the right revision of changes.

  3. After you hit next, you’ll get a couple options on how you want the merge to determine what a change is.  I use c# so I usually will ignore whitespace characters.

    Force the Merge will avoid tree conflicts where an incoming delete affects a file that is either not versioned or not modified locally.  I haven’t done any changes like that so I’m leaving it blank.

    Only Record the Merge is a bit complicated to explain but I’m leaving it blank here.  If you want to know more read the TortoiseSVN doc on Merging.

    Before you go to far TEST THE MERGE!

  4. By testing the merge first, you can see what’s being changes.  If there is too many changes, you might decide to only merge over the changes from one revision.  There are a lot of choices here but the TortoiseSVN documentation on Merging will help a lot.
  5. Merge it.

3. Resolving Conflicts

Merging is a complicated business.  You will have conflicts.  Fortunately, it’s “easy” to resolve them, but it takes time.

You’ll get a dialog similar to this, asking what you’d like to do for each change.  There’s nothing I, or TortoiseSVN can do to help you here.  It’s a manual process.  This is why it’s better to merge frequently so the changes are not so numerous.

4. Check and Test

At this point, I bet you think you’re done.  You’re mostly right.  All that’s left is to test your app and make sure it still works.  Good thing is, your working copy is only changed locally.  So you can always revert and try the merge again.

Happy Merging!

Author: Dirk Watkins

Dirk Watkins was born in Door County. He studied computer science and art at Carroll University in Waukesha, Wisconsin. Dirk now works as a web developer in Milwaukee programming mostly in C#, Javascript, T-SQL and the occasional regular expression. For design he likes to utilize as much standard CSS (positioning and styles) as possible. In his spare time Dirk brews beer, plays guitar, reads, listens to NPR, works on his house, and sleeps on quiet beaches.

Leave a Reply

Required fields are marked *.