When svn merge doesn’t quite cut it

Anyone that works with subversion will know that merging 2 branches is not always easy. Most of the time there is no issue, and you can merge one or multiple changes from one branch to another, but sometimes you end up with conflicts left right and center. This is done with the standard merge commands:

Single change:

svn merge -c 1234 svn://subversion/path/to/branch .

Range of changes:

svn merge -r 1234:1300 svn://subversion/path/to/branch .

The fun comes when the above get’s a little messy, lots of edits have happened on files, or file properties get changed. It’s at this point you have 2 options. The first being to step through the conflicts with a file editor and accept, modify, or edit each conflict by hand. This often drives me up the wall on large pieces of code as it can take a very long time. Especially when the only difference is a one line change, but the editor someone else used changed the line endings on the entire file.

At this point I revert the files, go and make a fresh cup of tea, and take the other option. This is the CLI tool named patch.

First you need to make the patch file, which is simply the svn diff outputted to a file on disc.

Single change:

svn diff -c 1234 svn://subversion/path/to/branch . > filename.patch

Range of changes:

svn merge -r 1234:1300 svn://subversion/path/to/branch . > filename.patch

This patch file can then be applied to the clean checkout with:

patch -p0 < filename.patch

You can then check that the patch has been applied correctly with a normal svn diff, and if you're happy commit the changes.

The patch approach to merges though does come with the cost of not having a complete revision log. As you will only have the commit post patch, and not be able to track who changed what line later if you need to know who introduced a rouge piece of code. This is not a massive issue, unless you work in an office that likes to blame people.

Leave a Reply

Your email address will not be published. Required fields are marked *