This project has moved and is read-only. For the latest updates, please go here.

Merge efforts overhead

Sep 13, 2011 at 9:32 PM

Our organization adopting TFS Branching guide. I'd like to estimate by how much should we increase development tasks duration if followed Merging and Branching guide.

So far we were using Release-By-Release branching approach which allow developers concentrate on coding and perform branching only for hot fixes. 

Sep 13, 2011 at 9:43 PM

An argument can be made that a sound branching strategy will reduce development time rather than increase it.

From a devleopment side, leaving aside the benefit of branching for release and post production hot fixes, we don't recommend branching for the sake of branching. But rather branching when the benefits outweigh the costs.
So for example, I can make extensive arguments why we advocate, at a minimum, a basic branching plan with a main branch, one development branch and one release branch.

So as not to be *too* repetitive let me refer you to this other thread in this forum:

Bill Heys
VS ALM Ranger

Sep 13, 2011 at 10:05 PM

Thanks Bill, indeed in most cases branching and merging facilitate project delivery. However our developers are experienced and disciplined enough to not break stable branch with untested source code. So we develop directly in MAIN branch.

Unfortunately due to real world obstacles we forced to perform branching just for the sake of branching. That pushy branching adoption form negative experience of TFS2010 product itself within the team.

So I'd like to gather opinions on how many man-hours should we attach to code checkins if accepted even Basic plan. 

Sep 13, 2011 at 10:10 PM

I would need much more information about how you develop applications before I would even begin to offer an estimate of man hours.

What *real world obstacles* do you face that *force* your team to *perform branching just for the sake of branching*? Who is pushing this?

Bill Heys


Nov 25, 2011 at 4:03 PM

artbern, if you have just one development team working the the DEVELOPMENT branch recommended by the BASIC branching plan, then there should be almost no time associated with merging it into MAIN. When you go to do the merge from DEV to MAIN, it will only show you discrepancies (items that were changed in BOTH places). But if you are a disciplined team, you will only have made changes in DEV and it will silently merge all those changes to MAIN without drama. This would literally take just a few minutes. I don't think it creates much friction at all. If you encounter issues with build quality before the merge, it will allow you to avoid merging until they are resolved.

On the other hand, I agree that in some cases, a disciplined team can preserve the stability of the branch to which they check in. That is the argument I make in my recent blog post  This post cites evidence of successful teams who check-in directly to MAIN. As Bill Heys said, it's all about ROI. But since the cost of merging a single development branch to MAIN is normally trivial, why would one not want this insurance? After all, it just takes one bad checkin to really wreck the build.

Nov 25, 2011 at 4:46 PM

I agree with David's comments. I also like his spin on "One bad apple can spoil the whole bunch" rephrased as "One bad check-in can really wreck the build"


Bill Heys
VS ALM Ranger