Multiple Branch Management - Need a better way

If you are having a problem using Fortress, post a message here.

Moderator: SourceGear

Post Reply
AjarnMark
Posts: 60
Joined: Mon Oct 29, 2007 4:22 pm
Location: Seattle, WA

Multiple Branch Management - Need a better way

Post by AjarnMark » Wed Jul 23, 2008 12:55 pm

I seem to have gotten my team into a bit of a mess with our branching and merging policy and am looking for recommendations on a better way or best practices. I have read Eric Sink's article series which got me started, but we went one level farther and it's causing headaches. In short, when merging branches, we are getting merge conflicts more and more often and in places I would not expect them.

In our current setting, TRUNK is our PRODUCTION GOLD copy of our software. When we are ready to dive into building the next version, we create a branch for those changes, developers work in that branch until complete and after that version has tested and been released to production, it gets merged back to TRUNK. I realize now that this is perhaps the inverse of Eric's recommendation, but it works fine with only one version in development at a time. Any Production Support bug-fixing gets done in the branch and later re-merged to TRUNK. So, for example, it would look like this:

$\MyApp\Trunk -- Source that produced current LIVE PROD version
$\MyApp\Branches\
------ 1.0 -- Version 1.0 built and released to PROD, merged to Trunk.
------ 2.0 -- Current development of next version.

In this scenario, fixes to 1.0 are done in the 1.0 branch and released. Those fixes are merged to Trunk AND to 2.0 so that 2.0 does not regress.

Now the twist. Suppose 2.0 is done with initial development and into QA. The 2.0 branch sits dormant until QA bounces bugs back to be fixed. The developers need to get started on 3.0 features. So, should 3.0 get branched from 2.0? Or should 3.0 get branched from Trunk and then Merge 2.0 to 3.0 so that 3.0 starts with all of the 2.0 changes? Or...?

Or, if need be, I can restructure how we're doing everything if you firmly believe that I have set myself up for nothing but nightmares. But it will be a significant change at this point, so please help me understand the same question... what is the appropriate plan for merging changes between multiple concurrent development branches?

Thanks in advance!

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Wed Jul 23, 2008 2:10 pm

Mark,

I'm really pretty confused by your description, and I think that a phone call would clear it up. Please email support at sourcegear.com ATTN: jeremy with your phone number and a link to this thread.
Subscribe to the Fortress/Vault blog

AjarnMark
Posts: 60
Joined: Mon Oct 29, 2007 4:22 pm
Location: Seattle, WA

Do-Overs!

Post by AjarnMark » Fri Jul 25, 2008 10:46 am

Just to close the loop...

Jeremy, thanks for spending the time on the phone with me. It is now clear that the approach I had setup was working fine when we had distinct breaks between working on versions because we juggled multiple applications, but as our schedule has compressed, we have narrowed our application pool, and as we are doing more and more concurrent development, I have set myself up for headaches. One of the biggest was that we ended up with a relatively new branch that actually turned stale while fixing up one of the others, and we had to merge forward changes into multiple branches... Ugh! Anyone else reading this post, do not do this! Rather than Fortress alleviating my headaches, I found a way to create more for myself.

We now plan to find a time to bite the bullet and flip our approach around 180 and go with the recommendation where TRUNK is our primary active development area (least stable) and then create release version branches at the point where we are stabilizing and preparing to hand off to our QA team. There will still be some development work in the branches as we address items brought up from QA efforts, or post-release bug fixes, but far less work, and much more easily merge-able back to the TRUNK for inclusion with future versions. We can then continue on with work on the next version in TRUNK. Also, Jeremy, thanks for the tip about Feature branches to address some of our concerns about work that we need to do and are still debating which version will actually include it.

Believe me, I love Fortress (and Vault / Dragnet in the past). You guys have alleviated many migraines that I had to deal with back when we were on Visual SourceSafe! And I'm sure I never would have gotten such good (and perosnal) service from Microsoft! You Rock!

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Fri Jul 25, 2008 12:06 pm

Thanks for the kind words, Mark. Let us know how we can help more in the future.
Subscribe to the Fortress/Vault blog

Post Reply