Clarifying Obfuscation Day of Designs
Feb 10

We use Subversion for version control with the TortoiseSVN and VisualSVN plugins. Using a version control system that supports branching and tagging is a must if you want to Always Keep Your Project Releasable and keep your HEAD clean (more on this another time).

Merging has been a source of frustration for the team – not the cleaning up of conflicts, but the actual process. We use the TortoiseSVN UI for merging and the process isn’t very intuitive so I’ve written a little guide. 

I’m assuming you have a branch you’ve been developing on and now want to merge that branch back into the HEAD.

1. Check in all edits you’ve made to your branch.

2. Checkout the latest revision of the HEAD (the head of the head) into a new folder on your local drive.

3. Right click on the folder and select Merge.

merge

4. Choose the Merge a Range of Revisions option and hit next (our svn server doesn’t seem to support mergeinfo, so we can’t use the second option. I think we need to upgrade).

merge_a_range_of_revisions

5. We want to merge from the point we made the branch to the latest revision of the branch. To do this, leave the Revision Range to Merge box empty. Otherwise, fill in the range you wish to merge. Hit next.

merge_range

6. Leave the default settings in the Merge Options page and hit the Test Merge button. It will show any conflicts that occur between your branch and the HEAD.

merge_options

7. If satisfied, hit the merge button. Your branch should now be merged with the HEAD in the Project Head folder.

8. Edit any conflicts. If a lot of changes have been made to the HEAD while you were working on your branch, this could take some time. Avoid having too many conflicts by merging early and merging often.

9. Open up the project and make sure everything runs and that all tests pass. This is particularly important if you’re not operating in a CI environment.

10. If everything runs ok, all tests pass and you’re completely satisfied, check in the project to the HEAD. Your working copy is now the head. YOU SHOULD NEVER CHECK ANYTHING TO THE HEAD THAT WILL BREAK THE BUILD. If another developer cannot check out the HEAD and have it compile, you’ve gone wrong.

11. Check out a fresh copy of the HEAD and make sure it builds and all tests pass. If not, fix them and check it back in.

12. Your working copy should contain your features, the features of the other developers on the project and all that went before. Everything should build and feel fresh and clean. Now you can re-branch and keep on coding more features!

Leave a Reply