Best practice with branching source code and application lifecycle

Question

We are a small ISV shop and we usually ship a new version of our products every month. We use Subversion as our code repository and Visual Studio 2010 as our IDE. I am aware a lot of people are advocating Mercurial and other distributed source control systems but at this point I do not see how we could benefit from these, but I might be wrong.

Our main problem is how to keep branches and main trunk in sync.

Here is how we do things today:

1. Release new version (automatically create a tag in Subversion)
2. Continue working on the main trunk that will be released next month

And the cycle repeats every month and works perfectly. The problem arises when an urgent service release needs to be released. We cannot release it from the main trunk (2) as it is under heavy development and it is not stable enough to be released urgently.

In such case we do the following:

1. Create a branch from the tag we created in step (1)
2. Bug fix
3. Test and release
4. Push the change back to main trunk (if applicable)

Our biggest problem is merging these two (branch with main). In most cases we cannot rely on automatic merging because e.g.:

• a lot of changes has been made to main trunk
• merging complex files (like Visual Studio XML files etc.) does not work very well
• another developer / team made changes you do not understand and you cannot just merge it

So what you think is the best practice to keep these two different versions (branch and main) in sync. What do you do?

Answer 1

I think your approach to branching and merging is OK, but if the main problem is that the code base is quite unstable, that's what you need to focus on and minimise.

The primary thing to ensure is that the code base has good separation of concerns. Dependencies between various components need to be isolated and reduced. This should solve the majority of your problems. Also following practices such as single responsibility principle will help.

If a major architectural change needs to occur, it should take place in its own branch, and then merged back into main once fully tested and 'stable' (within reason). This may be painful and challenging but it also should be rare. If you have good testing practices in place then risk is minimised.

It may also help to change to a distributed version control system. This should give you a trunk that is stable, with different features merged in from different branches when they are ready. You will still have pain merging if the code is too interdependent, but you will have more control.

Looking at this from another perspective, also consider increased communication amongst your team. Run regular agile-style standup meetings. Consider where team members sit and how that can help. If a complex merge needs to take place, it may not be such a bad thing - use a pair programming approach that will give understanding to both parties.

Answer 2

I tend to look at it from pretty much the opposite way:

• Trunk should always be production-ready code (after your first initial release, that is).
• There should be a development-type branch that runs parallel to trunk, where your monthly development happens. Every month when it comes to release time, this gets merged into trunk, tested, and then released.
• Hotfixes can then easily be made in your trunk and checked in, and always be deployed successfully. Then make a patch from the hotfix, and apply it to your develop branch.

Of course, this workflow is much better suited to something that isn't SVN, because good branching and merging is something that's quite painful in SVN, regardless of your workflow. In my experience, merging in SVN should nearly always be done manually, because it just doesn't work, and there's no real way around it.

Answer 3

Lately, I've been advocating a philosophy of "branch and merge" as a last result. I think it is the unfortunate truth that dealing with code merges from branches is not a technical problem, but it is a task that cognitively difficult: I think it is simply that the human brain does not track enough details to make it easy. Moreover, I have yet to see branching and merging actually work in practice. Once code is branched, experience tells me that it is nothing but trouble to merge it again.

Answer 4

A disciplined release-on-main approach works well.

SVN branching is not designed to be flexible. I would suggest your first problem lies in SVN; moving from that will open up new options.