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:
- Release new version (automatically create a tag in Subversion)
- 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:
- Create a branch from the tag we created in step (1)
- Bug fix
- Test and release
- 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?
Best Answer
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.