merge hell (noun) merge hell occurs when you have branches made from branches, with work on similar features or the same pages between the two branches and you then need to merge a branch into a branch, and then that branch into trunk. The time you spend doing those merges will now be known as merge hell.

Most of this can be avoided by implementing a good SVN process – SVN processes can vary from company to company, but the general work-flow should be as follows:

1. A developer or group of developers is given new task, requirements or specifications. They will need to keep these additions, features, changes in a new branch – so you create a branch from trunk, where trunk is an exact replica of your production code.

svn cp http://svn.ourwebsite.com/repos/trunk http://svn.ourwebsite.com/branches/newfeature

2. The team or individual does all their work inside the newly created branch. Once the work is done* it is time to merge trunk into our branch. You can do this by changing into the directory of the branch and first testing the merge process by using a dry run.

cd branches/newfeature

svn merge --dry-run http://svn.ourwebsite.com/repos/trunk

At this point there is two outcomes, a perfect merge with no conflicts – or merge hell.

If you find yourself in merge hell, you’ll have to defend your branch by manually defeating conflicts. Merging conflicts is an art, often times you’ll need to pull developers in and go line by line to figure out what needs to stay and what can go. Merge hell is multiplied by the size of your development team concurrently working on projects that have branched from trunk and merged back. But by first merging trunk into your branch then reintegrating your branch back into trunk hopefully you can stay out of merge hell.

Continuing on, once your conflict free – you can then run the merge.

 svn merge http://svn.ourwebsite.com/repos/trunk

Then to signify your merge of trunk you can commit merged files to the branch.

svn ci -m "Merged from trunk"

3. Now is a great time to test your branch, in fact you will need to, to ensure that nothing was broken with the addition of your new code and the merging of trunk into your branch. See *Once the work is done, because those same things may happen here as well. So, once the work is done – we have bug-free code*.

If we have made it this far – your code has passed some sort of QA and/or testing, and those processes, including fixing the errors that those processes uncover, take time. Within this time, especially within larger teams, another feature may have made it into trunk, giving merge hell another chance to show its face. If there is new features in trunk you’ll need to re run the above merge process in your branch (go back to step 2, do-not pass go, do-not collect $200). Potentially, your branch could be stuck in this step indefinitely, depending on the planning and communication levels of your team(s). One thing is for sure you do-not want to be stuck at this step on the day of a production push, you want to be beyond it.

4. Time to integrate (re-integrate) your branch into trunk. And, since your branch is now a working copy of trunk with your work/feature included this should be merge hell and file conflict free.

Check out a copy of trunk, merge in your branch and commit to trunk

svn co http://svn.ourwebsite.com/repos/trunk trunk

cd trunk

svn merge --reintegrate http://svn.ourwebsite.com/branches/newfeature

svn ci -m "Re-integrated new feature into Trunk"

*Once the work is done – often times this can refer to when the developer feels he is done coding, or this may also refer to a full fledged qa hand off prior to merging trunk, or this may refer to just the running of selenium and php unit tests, or even a stakeholder review – whatever the case may be at your company.

*Bug-Free Code refers to software with fewer bugs.