Question

We are using feature branches in Subversion for our development which is a very convenient way of keeping code within version control that is not yet ready for the mainline. However, whenever I go to merge the feature branch revision into the mainline it is a pain. Right now I go through the following steps:

1. Check out the original feature branch revision to a new directory
2. Perform a difference between my current development and the original feature branch directories with a tool like Beyond Compare
3. Check out the current mainline revision to a new directory
4. Merge the new/changed files into the current mainline directory.
5. Perform a difference using my IDE to ensure all of the files are properly checked out/added to subversion
6. Compile and test
7. Commit

It seems to me that there is a lot of room for errors in this process and it makes me nervous every time I walk through the steps. Granted, everything is checked into Subversion on my feature branch, so a mistake at any step is recoverable.

I believe that Subversion 1.5 has a way to merge a branch into the mainline, but we are still using Subversion 1.4. What are other people using to simplify the steps of merging a feature branch in Subversion into their mainline development? Are you using different tools? Are you utilizing the merging feature in Subversion 1.5?

Answer 1

I am using the new –reintegrate feature of Subversion 1.5 at the moment and I think it’s amazing. It’s much easier and much less error-prone than the manual way. The downside is, however, that the new merge features require both the repository and the client to be on 1.5 and the changes to the 1.5 repository preclude use by any clients other than 1.5… so to get the merge feature, it’s basically an all-or-nothing scenario.

As to your original questions, you just need to keep very rigorous track of which main branch revisions you’ve merged into your working branch during development. Even with the –reintegrate feature of 1.5, however, it’s still important to ensure that the reintegrated working copy of the main branch looks correct and compiles before you commit. It just basically makes life a lot easier (especially for longer-lived feature branches) because you don’t have to keep rigorous logs as to what you’ve changed and when you’ve integrated changes from other branches to your feature branch.

The release notes documentation at subversion.tigris.org is very well written and I would recommend looking it over briefly to see all the changes between 1.4 and 1.5 and for a good description on the new merging facilities.