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

New TFS User - Multiple Releases - Branching/Merging help

Jul 3, 2012 at 6:47 AM
Edited Jul 3, 2012 at 10:33 AM

Hello,

new user to this forums as well as pretty new to TFS.

Currently at my company we use a mix of no source controll as well as VSS. The powers that be has decided that we should start using TFS 2010. Now we are trying to think of a development strategy using TFS. We need to support several releases of our product(s).

We are thinking of using a branch-per-feature strategy, and branch releases according to the following picture:

http://img193.imageshack.us/img193/3594/06aj.png

(Don't know if the picture will be emedded, so here is a direct link: http://img193.imageshack.us/img193/3594/06aj.png)

  • Branch-per-feature, mergre back when done.
  • Development is done on MAIN
  • We branch of (at the same time) to R1, R1.0 and R1.0.0 when branhing for the R1 release. The same strategy is used for R2 when we get that far in development.
  • Branches R1.0, R1.1, R2.0, etc must be supported at the same time.

If we look at one of the release branches, e.g. R1 the strategy is the following. R1 branch is the "development" branch of the R1 branch. Here some small features will be added or existing features expanded. I guess this would correspond to the Service branch. The R1.0, R1.1, etc branches will only have bugfixes, and will then be released as R1.0.1, R1.0.2, R1.1.1, R1.1.2, etc. So the R1.0, R1.1 branches will correspond to the hotfix branches (?).

If a customer is on the R1.0 branch, it is not a certainty that he will upgrade to any later branch (e.g. R1.1, let alone R2.x), so it is important that we support each Rx.y branch with further Rx.y.z bugfixes/hotfixes. If (BIG if) at some later date we get all customers off of a specific hotfix branch (or service branch), that branch will be made read-only and no further releases from that branch will be made.

So this is our overall strategy. Does is sound good ? Is it completly wrong ? In between ?

If it does sound good, I have a couple of questions.

1. Lets say there is a bug that affects the R1.0, R1.1, R2.0 and R2.1 branches. It needs to be fixed. In which branch should this bug be fixed ? Should it be fixed in the R1.0 branch, then merged to the R1 branch and then that merged to the MAIN branch ? What about the other Rx.y branches ? Should the fix be a baseless merge from the R1.0 branch to the R1.1 R2.0 and R2.1 branches ?

2. Lets say we want to add a new feature to the R1 branch (and in this case release it later as R1.3). Should that feature then be added to the R1 branch and then merged back to the MAIN branch ? What about the R2 branch ? Should the feature be a baseless merge from R1 to R2 (if the feature is to be added to the R2 branch) ?

That's is for now. Any help and comments ("Don't do it like that, do it like this: ", "You're way off base ...") would be appriciated.

Thank you in advance.

//K

// EDIT: Speeling, clarification.

Jul 3, 2012 at 8:15 PM

For those new to the platform, I recommend that you choose one of the branching strategies described in some detail in the TFS Branching Guide available in the donwloads section. Those plans have the advantage that many people have used them and proven that they can work. The plan you described does not sound like any of them.  The best way to learn those is to make a copy of your live code to a practice area in source control, then experiment on the published plans until you get the hang of it.

In particular, I am confused by several aspects of your post. I have an idea of what "Branch per feature" means to me, and it is not at all like what your picture shows. Here is a post Bill Heys and Willy-Peter Schaub wrote that explains it in the way I understand "branch per feature" to mean : http://msdn.microsoft.com/en-us/magazine/gg598921.aspx.  Their model has you creating development branches off of main, and developing in those branches, not in Main. Then merging to Main when the feature is done. I am not generally a fan of using "Branch per Feature" for the reasons cited here http://agileinaflash.blogspot.com/2010/04/branch-per-feature.html. But it can be made to work if needed, if you heed the risks indicated.

If you study those plans they will illuminate some of your later questions. In particular, I would ask you to consider the consequences of supporting multiple versions with bug fixes for your customers. The more versions for which you promise support, the more expensive your support costs will be.  Your current experience will inform this. For example, how many versions of your product do you support today with promises of bug fixes? And what do you do when you have to make such fixes?

Jul 4, 2012 at 7:31 AM

Thank you davidkallen, I appricate you taking the time to answer my questions.

Yes, re-reading my post it does seem a bit confusing :-). The branch-per-feature that you describe is exactly how we thought of it. Branch from MAIN, develop, merge back to MAIN.

Having read the Branching Guide for 2010 (TFS_Branching_Guide_Main_2010_v1.pdf) I think the strategy that best describes what we envisioned would be the Mature Branch Plan (Figure 17 on p.19).  If we look at my original (bad) picture the R1 and R2 branches would correspond to the Service Pack branches in Figure 17. The R1.0, R1.1, R2.0 and R2.1 would corresond to the HotFix branches, and the R1.0.0, R1.0.1, R1.1.0, R1.1.1, R2.0.0 and R2.1.0 would correspnd to the RTM branches.

What is a bit confusing is where bug fixes should be developed and to where they should be merged. If we again look at figure 17, what if there is a bug that affects the HotFix branches R1(SP0), R1(SP1) and R2(SP0). Should the bug fix be done in the R1(SP0) Hotfix branch (which will then be released as .e.g R1(SP0, HotFix1), then merged back up to the R1(SP) branch, and then the R1(SP) branch merged back to MAIN so that MAIN also contains the fix ? And what about the R1(SP1) and R2(SP0) branches ? How do they get the bug fix ? Should a baseless mergre from the HotFix branch R1(SP0) be made to the R1(SP1) and R2(SP0) branches ?

The same question for new features as well. In figure 17, I interpret it as MAIN being merged to the R1(SP) branch just before R1(SP1) is branched. But doesn't this mean that all changes (large and small) done to MAIN after R1 was branched will be merged to the R1 branch ? What we would whant is for MAIN to continue development towards R2 and not merge anything to the Service Pack Branch R1(SP) after it has been released. Then the question becomes, if we want to add a new (small) feature or expand an existing feature in the R1(SP) branch, should that feature be developed in the R1(SP) branch and then merged back with the MAIN branch (so it also contians the feature) ? And what about if R2(SP) branch also need this new feature ? Should a baseless merge be done from the R1(SP) branch to the R2(SP) branch ?

Yes, we realize that supporting multiple service pakcs with the latest hot fix requries extra work, and hopefully we can get most customers to upgrade to the lates service pack and hot fix for a specific release branch (R1, R2), but there are those customers that require a specific version and will not uppgrade to the latest service pack branch for a specific release. (Has to do with certification)

As for the branch-per-feature strategy, would it work if doing most work directly on the MAIN branch and only doing a branch-per-feature for very large and/or disrupting changes, i.e. having a sort of mixed "devleop on MAIN, branch-per-feature if necessary" strategy ?

(As a side note, our current strategy is... well, non-existing. We mostly only have one version where the latest code is the latest version, with bugfixes, new features, new bugs. etc all in one. And mostly no source controll. So telling a customer to upgrade to the latest version to fix a bug, just to get a new bug introduced is no fun.)

Again, thank you for your time.

//K

Jul 4, 2012 at 4:25 PM
Let's step back and think about the big picture here. I asked about your current strategy because it has implications for how far you can leap ahead. Since your current strategy is as simple as it gets, with all the code in Main and no branches, then the ideas you are proposing may be overly ambitious. It is easier to learn to walk before you run. Branching and merging are as much art as science. So, regardless of what plan you try, I advise you to first try making a copy of your source tree in a TFS practice project, and testing your ideas in a safe place where you feel free to experiment. That way you can try the scenarios you are describing rather than simply asking about them and trying to imagine what happens. Or you can start with a simpler branch plan and gain experience before you go to the mature plan. Or you could do have the best of both: choose a simple plan to start, while you experiment with more complex plans.
Regarding your question about where to fix the bugs, I am reluctant to offer an opinion as I have not ever supported bugs in multiple releases before. I have fixed bugs in the latest release branch only, then merged that back to Main. Then forward integrated (Merged) into the development branch to pick it up for future work. I've thought about how to support multiple branches, but you will be better served by someone who has actually done this.
Good luck,
David Kreth Allen


On Wed, Jul 4, 2012 at 1:31 AM, au819201923 <notifications@codeplex.com> wrote:

From: au819201923

Thank you davidkallen, I appricate you taking the time to answer my questions.

Yes, re-reading my post it does seem a bit confusing :-). The branch-per-feature that you describe is exactly how we thought of it. Branch from MAIN, develop, merge back to MAIN.

Having read the Branching Guide for 2010 (TFS_Branching_Guide_Main_2010_v1.pdf) I think the strategy that best describes what we envisioned would be the Mature Branch Plan (Figure 17 on p.19). If we look at my original (bad) picture the R1 and R2 branches would correspond to the Service Pack branches in Figure 17. The R1.0, R1.1, R2.0 and R2.1 would corresond to the HotFix branches, and the R1.0.0, R1.0.1, R1.1.0, R1.1.1, R2.0.0 and R2.1.0 would correspnd to the RTM branches.

What is a bit confusing is where bug fixes should be developed and to where they should be merged. If we again look at figure 17, what if there is a bug that affects the HotFix branches R1(SP0), R1(SP1) and R2(SP0). Should the bug fix be done in the R1(SP0) Hotfix branch (which will then be released as .e.g R1(SP0, HotFix1), then merged back up to the R1(SP) branch, and then the R1(SP) branch merged back to MAIN so that MAIN also contains the fix ? And what about the R1(SP1) and R2(SP0) branches ? How do they get the bug fix ? Should a baseless mergre from the HotFix branch R1(SP0) be made to the R1(SP1) and R2(SP0) branches ?

The same question for new features as well. In figure 17, I interpret it as MAIN being merged to the R1(SP) branch just before R1(SP1) is branched. But doesn't this mean that all changes (large and small) done to MAIN after R1 was branched will be merged to the R1 branch ? What we would whant is for MAIN to continue development towards R2 and not merge anything to the Service Pack Branch R1(SP) after it has been released. Then the question becomes, if we want to add a new (small) feature or expand an existing feature in the R1(SP) branch, should that feature be developed in the R1(SP) branch and then merged back with the MAIN branch (so it also contians the feature) ? And what about if R2(SP) branch also need this new feature ? Should a baseless merge be done from the R1(SP) branch to the R2(SP) branch ?

Yes, we realize that supporting multiple service pakcs with the latest hot fix requries extra work, and hopefully we can get most customers to upgrade to the lates service pack and hot fix for a specific release branch (R1, R2), but there are those customers that require a specific version and will not uppgrade to the latest service pack branch for a specific release. (Has to do with certification)

As for the branch-per-feature strategy, would it work if doing most work directly on the MAIN branch and only doing a branch-per-feature for very large and/or disrupting changes, i.e. having a sort of mixed "devleop on MAIN, branch-per-feature if necessary" strategy ?

(As a side note, our current strategy is... well, non-existing. We mostly only have one version where the latest code is the latest version, with bugfixes, new features, new bugs. etc all in one. And mostly no source controll. So telling a customer to upgrade to the latest version to fix a bug, just to get a new bug introduced is no fun.)

Again, thank you for your time.

//K

Read the full discussion online.

To add a post to this discussion, reply to this email (vsarbranchingguide@discussions.codeplex.com)

To start a new discussion for this project, email vsarbranchingguide@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
David Kreth Allen
612-374-1119

Jul 5, 2012 at 5:54 AM

Thank you David for you answer.

As you suggested, I think we'll start with a simple plan for the production code, and have a more "complex" plan in a testing place/project where team members can do testing with branching and merging and gain some experience on how things work. Then we'll see how we move on from there.

If anyone else has any comments or suggestions on  fixing bugs (or dos/dont's) when maintining multiple releases in several branches, feel free to comment.

Again, thank you for your time David.

//K

 

Jul 5, 2012 at 2:21 PM
you are welcome. And I hope someone with experience in bug-fixing across releases does comment because that question comes up often, and I am interested in hearing how people handle it.


On Wed, Jul 4, 2012 at 11:54 PM, au819201923 <notifications@codeplex.com> wrote:

From: au819201923

Thank you David for you answer.

As you suggested, I think we'll start with a simple plan for the production code, and have a more "complex" plan in a testing place/project where team members can do testing with branching and merging and gain some experience on how things work. Then we'll see how we move on from there.

If anyone else has any comments or suggestions on fixing bugs (or dos/dont's) when maintining multiple releases in several branches, feel free to comment.

Again, thank you for your time David.

//K

Read the full discussion online.

To add a post to this discussion, reply to this email (vsarbranchingguide@discussions.codeplex.com)

To start a new discussion for this project, email vsarbranchingguide@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
David Kreth Allen
612-374-1119

Jul 12, 2012 at 9:57 PM

There may not be an easy "branch/merge" solution to the nee to apply a bug fix to two separate releases code. A lot depends on how different the underlying code is in the two releases. In theory, the bug fix might be the only change to the file(s) in the two releases. Or, the underlying code may have been rew ritten or refactored from Release n to Release n+1. 

If the fix is made to the latest release, then it can be merged (RI) up to Main (and perhaps ongoing Dev branches). But, if the fix is made to a prior release (Current -1) and ALSO needs to be made to the current release, you may consider making it first in Release n-1 Servicing branch, merging (RI) to Main, and then merging t(FI) to Release n Servicing branch. Or you may consider a baseless merge between Release n-1 Servicing and Release n Servicing.

The best option, however, may be to make the code fixes directly in the affected Release Servicing branches. A clear advantage to this non-merge approach is you can more easily control the changes and avoid "merge-contamination", where you inadvertantly overlay code or files in one release with newer or older code from the other release during the merge.

Consider the compexity of the code fix and balance that against the risks of introducing new bugs during an improper merge, and choose the best option for you and your organization.

Bill Heys, VS ALM Ranger

Jul 17, 2012 at 9:58 AM

Hello Bill and thanks for taking the time to asnwer my question.

The anwser you give pretty mutch answers all the thinks I wanted to know :-).

I also at first thought that fixing the bug in each affected branch seperately would be the "right way" but was under the impression that "coding the same thing twice" was a big NO-NO instead of merging one fix to several branches. But as you put it, it really depends on how far the code has deverged in the different branches, and if there is an easy way to merge just "the fix" or if coding/fixing the bug in each branch seperatly is less "riskier" than (potentially) merging unwanted code.

Again, thank you very much for your answer !

// K