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!
Multiple Branch Management - Need a better way
Moderator: SourceGear
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.
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
Do-Overs!
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, 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!
Thanks for the kind words, Mark. Let us know how we can help more in the future.
Subscribe to the Fortress/Vault blog