Good way to limit merge cost for feature Branches in SVN

Question

Can anyone recommend workflow/use patterns that reduce the cost/complexity of merges when using Agile with SVN?

I know that use-git is an answer, but I'm trying to figure out how to solve my problems process wise where I am before throwing a new tool into the mix because I don't have the cycles to handle the disruption at present.

We have recently switched from an unstable trunk model with maintenance and stabilization branches off of trunk to stable trunk with feature branches. We have trunk with older maintenance branches for sustaining and newer team branches with feature branches off of them.

Team develop features and push them to the team branch and then up to the trunk. Sometimes the features are also merged between feature branches. We run into some issues with tree conflicts (especially when a changeset is pushed both to trunk and to another feature branch).

When we need to move changes over to sustaining maintenance branches or pull changes from them to trunk it is very difficult. The trunk and the maintenance have drifted quite a bit.

The merges are getting in our way and I'm trying to determine if there's some process problem where we are cutting against the grain of SVN and causing problems. I'm looking for a better branch management strategy that reduces the effort.

Can anyone recommend good articles, strategies or tools?

Answer 1

A few things I can think of that help reduce possible conflicts:

• Make sure your working copy is at a single revision, by running svn up on the root of the working copy.
• Make sure you have no local modifications
• Make sure there are no switch children (this happens when you switch a directory inside the wc, instead of the wc itself)
• Make sure the working copy is checked out with depth=infinity, ie no sparse working copy

Answer 2

Dependant on how stand-alone certain features are, you could consider making features modules, and include them (possibly pinning a certain revision) with svn:externals. It depends on wether the codebase/project is suited for this kind of modularisation though.

Answer 3

SVN wasn't really designed for a feature-branch workflow, as you can probably tell by now. If you're going to approach this, try Git or another DVCS and things will be much better for you. It is well worth the investment to switch.

Answer 4

I would recommend:

• Keep your feature branch in sync with the trunk. Make this a regular task, it takes no time at all if you do it every couple of days. When you are ready to drop the work to the trunk, ensure it's given a healthy dose of QA and use the reintegrate merge. Reintegrate interrogates the svn:mergeinfo property on files and folders to ensure that the changes synced from the trunk to your feature branch are not synced back down ('cyclic' merges).

• Ensure you only branch off the trunk, do not 'cascade' branches off other branches. We've had cases where the COPY-TO property on a renamed file was not tracked when the file was merged back. This can result in SVN not deleting things correctly, and this problem is compounded if you have cascaded branches.

• In the past we had major problems with svn:mergeinfo: there were bugs in the system when it was first introduced and it ended up putting mergeinfo on pretty much every file and folder. This caused us more harm than good when merging, it just got itself confused, so we decided to purge mergeinfo on every file and folder apart the root folder of our repository. This then acts as a good summary of branch activity. If you do this you don't get all the features of SVN tracking folder/file moves, but we had so many problems it ended up just being quicker to manually resolve tree conflicts where necessary. Note: this policy is arguable. I do not recommend doing this unless you really need to, but it has worked well for us.

• Talking of folder/file moves, don't go crazy restructuring your codebase. Only move files and folder if it's really necessary and if you do ensure you communicate the changes to your team.

• The same goes for renaming, don't rename stuff without good cause. Filenames in the repository are case-sensitive, but Windows files are not case-sensitive. So if you change a file from 'foo.txt' to 'Foo.txt' and then back to 'foo.txt', during a merge SVN will attempt to delete, add, and then re-add the file. It thinks it's different but the filesystem will complain and it will bail out of the merge. These are very frustrating cases.

• Following on from Sander Rijken's comments: along with making sure you don't have local modifications, it's also good practice to ensure you regularly delete any unrevisioned files. If you have a file floating around which a merge attempts to write over SVN may get confused. We have a few Ruby housekeeping scripts for cases like this.

• Pay attention to tree conflicts. They are easy to resolve if you merge in small doses. You just have to look the history of changes on the file on the codeline you are merging from and reapply them manually to the destination. This is the worst case, but if you have the correct person responsible for the merge, e.g. the lead on that project with an understanding of the work, then they can be resolved relatively quickly.

• Finally, ensure you keep your SVN clients up to date.

• Oh yes, and having a good merge tool can make the whole process a lot less painful. I use Araxis, but I've heard the merge tool in SmartSVN is good too.