Unclean MAIN

Jan 19, 2012 at 7:09 PM
Edited Jan 19, 2012 at 7:23 PM

I need some guidance on what to do.

We converted from SVN to TFS and now have a minor issue with how we are going to release. We are using the advance branching plan and it would work fine but this one case we are having problems with.

To keep it short, because of how source control was being executed in SVN we have some completed items in MAIN from vNext and vNext+1 (all weaved together). We've been building out of a development line (vNext) and making any defect fixes in the line and giving it to a customer to do UAT testing. (I know this ideally should be done in MAIN). Now the issue is that we want to release this version but we don't want vNext+1 features in this release. So as a result we can not make the release branches off of MAIN or it will include some of vNext+1 features.

What I was thinking about doing is making a release branch off of the development line (DEV1) and merging it into MAIN. Once vNext+1 (DEV2) gets completed we then go back to the suggested way of making release branches. 

Which is the best possible solution for this circumstance?

Thank you!

(Another option but probably wrong is making the development line MAIN and reparent several other concurrent branches to be a child of DEV1.)

Jan 19, 2012 at 8:14 PM
If I understand you correctly, vnext and vnext+1 are both peers, directly branched off of MAIN. Is that right? If so, your starting point is not so bad.

I agree that you need some transition plan to get you from where you are to where you want to be. I don't see why something like your suggestion would not work. But let's be careful here because the devil is in the details. Let me describe one approach that is in the spirit of your suggestion but may be slightly different:

Once vnext is ready to release, merge it into Main so that vnext+1 has the latest changes in the upcoming release. Then rename vnext folder in Source Control Explorer to be ServicePack. Then branch HotFix off ServicePack, and Release off HotFix. If you look at Figure 12 in the Advanced Branch Plan, your branch structure should match this almost exactly except vnext+1 is what is labeled as Development. After all, both vnext and vnext+1 are directly off Main, right? That is what makes this work. At this point, your Branch Hierarchy should look exactly like Figure 13. Advanced Branch Plan - Branch Hierarchy Visualization.

Now the only remaining oddity here is that your source control folder structure probably has ServicePack (formerly named vnext) under a development folder. That is a weird place for a set of service pack, hot fix, and release branches to live. So you can use the Move command in Source Control Explorer to put that under a RELEASE container. At this point your source control folder structure should resemble Figure 14. Advanced Branch Plan - File and Branch structure.

Now, you have just transformed your branch plan to match the advanced branch plan, and your folder structures to match as well. At this point, vNext is launched and you are on the Advanced Branch Plan without any kludges or variations required. Just follow that plan as designed and you should be fine.

If you rehearse this in a sandbox environment, you can verify for yourself that the branch hierarchy and folder structures look as you wish them to.


On Thu, Jan 19, 2012 at 2:10 PM, ssanders <notifications@codeplex.com> wrote:

From: ssanders

I need some guidance on what to do.

We converted from SVN to TFS and now have a minor issue with how we are going to release. We are using the advance branching plan and it would work fine but this one case we are having problems with.

To keep it short, because of how source control was being executed in SVN we have some completed items in MAIN from vNext and vNext+1. We've been building out of a development line (vNext) and making any defect fixes in the line and giving it to a customer to do UAT testing. Now the issue is that we want to release this version BUT we don't want vNext+1 features in this release.

What I was thinking about doing is making a release branch off of the development line (vNext) and merging it into MAIN. Once vNext+1 gets completed we then go back to the suggested way of making release branches.

Is this the best possible solution for this circumstance?

Thank you!

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
“Instead of complaining that the rose bush is full of thorns, be happy the thorn bush has roses.” -Proverb

Jan 20, 2012 at 1:25 AM
Edited Jan 20, 2012 at 1:25 AM

You are right. vNext and vNext+1 are in fact peers.

Thanks for comfirming and adding onto what to complete next.

Jan 30, 2012 at 5:00 PM
Edited Jan 30, 2012 at 5:10 PM

I now have a bit more complicated question.

The previous branching plan was to have one dev line and one MAIN. To maintain database changes, they were maintaining script changes by adding scripts to a folder and incrementing a number on each sql script and moving them from a dev line to MAIN. No pattern followed by the guidance package here. So I've been working on a plan to convert them over to a Database Project and this was my plan.

We are ready to merge vNext  into MAIN and it looks like it will not be too difficult. However prior to this I am wanting to make the transition from an the old way databases changes were happening. I want to implement a Database Project in that branch and and merge it into MAIN. So now vNext will be referred to as vCurrent (after the physical merge has been done).

Now that the MAIN branch will have the new Database Project and the Release branches will have the database project, vNext and vNext+1 will also need to be converted. I am planning to merge the project (FI) to the two dev branches, update these databases to vCurrent (which should not have any signifcant schema changes so it should be relatively easy). So now vCurrent will be throughout all branches.

For vNext and vNext+1 any scripts that have been put into these dev lines, I will run against a database that is vCurrent. After this is done I will update the Database Project off of the database that has vNext and vNext+1 changes in it.

This to me seems okay to get back on the Advance Branching plan. What do you think?

Jan 30, 2012 at 6:46 PM

What specifically do you have concerns with?  

The two process changes you are proposing seem independent to me. So you can certainly tackle them at one time if you wish. But if you have uncertainty, you could tackle them one at a time, in either order, I think. 

The question I would ask you is what you have in the way of environments. If you introduce a release branch for source code, you will want to branch your database scripts and projects as well. If they are all under MAIN this will happen automatically, which is good. And you will want a pre-production environment, perhaps named FIX, that is used to develop, test, and deploy production fixes. Do you already have that environment? It could be a complete and isolated environment, or merely a naming convention used with a few test servers and databases.