Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
1  
Make sure you check out tfsbranchingguideiii.codeplex.com (not posting as an answer since it doesn't directly address your question, but I always recommend it to people looking to improve their TFS branch-fu). Perhaps one of their branch plans will give you an idea about how to improve your setup. –  nlawalker Feb 12 '11 at 16:59
add comment

4 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
2  
What VCS's have you tried? The ease of a merge depends greatly on the VCS being used. –  alternative Feb 11 '11 at 0:15
    
A lot of newer VCSs actually handle merging really well. Sometimes conflicts will still occur, but they tend to be actual conflicts, not the fake ones reported a lot of time by SVN. –  sevenseacat Feb 11 '11 at 3:50
    
I've tried several SCM systems. Most merge tools can slam together two pieces of text with varying amounts of success. However, no merge tool can tell if it got the right result. I've seen too many bugs slip through because some programmer decided to trust a merge tool. –  smithco Feb 11 '11 at 4:05
1  
Merge tools aren't supposed to slam together two pieces of text. They are supposed to merge the changes from the parent commit; huge difference. –  alternative Feb 11 '11 at 11:56
    
Merge tools do not understand code. All they can do is take two different pieces of text and try to cleverly reconcile them. I can't emphasize enough how many times I've seen bad merges slip though and cause build failures and bugs. Every merge must be considered risky and the results reviewed by a human and pass the battery of tests before committing the merged changes. It's a complicated process and should be done infrequently. –  smithco Feb 11 '11 at 18:18
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.