Merge tracking with Subversion 1.6

I am now running Subversion 1.6 for my client’s SVN repositories. I upgraded mainly to take advantage of the Merge tracking introduced in Subversion 1.5, and improved in 1.6. In particular, Subversion now creates its own “mergeinfo” entries, so you no longer have to use the svnmerge.py script. Subversion 1.6 now has better detection of “tree conflicts” – essentially, problems with the local working copy caused by renames, missing files, etc.

I used the new release of VisualSVN Server to install and upgrade SVN in a painless way (see earlier post on VisualSVN Server). The new version installs over the top of the previous one, so back up your SVN repositories first.

An important part of the Subversion philosophy is “don’t break things”. Even though VisualSVN Server 2.0 runs Subversion 1.6, the underlying repository format is not upgraded automatically, meaning that the new merge tracking feature is still not (yet) available. To get this working we simply need to run “svnadmin upgrade PATH”, like this:

> svnadmin upgrade D:\Data\Svn\DevDoctor
Repository lock acquired.
Please wait; upgrading the repository may take some time...

Upgrade completed.

Following a working copy svn update, you can run svn merge. In this case, I used TortoiseSVN:

Here, we were merging from the development branch, so I selected Reintegrate a branch. Once the correct settings have been chosen, you can even “Test merge”, which gives you a report of what would happen if you went ahead with the merge. When the changes are successfully merged, Tortoise shows the results:

As normal, the merge needs to be committed, but the crucial difference after the commit succeeds is that Subversion itself has tracked the merge using the mergeinfo property:

You can see that an svn:mergeinfo property has been set on the folder, showing the branch from which the merges were done, and the revision numbers (here, 400-409).

All this means that merging (both from branches to trunk, and from trunk to branches) is all much less tricky and error-prone than before (with Subversion 1.4). Subversion 1.6 is also noticeably quicker than 1.4 for all operations so far.

Further reading: http://scm.jadeferret.com/subversion-16-new-features-explained/

Join the discussion...

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.