Proper source control management depends on a healthy organization of your source control tree. If you setup your tree properly it will give you both stability and flexibility when it comes to your source code. Setup isn’t difficult, it just requires some planning and sticking to some proven principles.
The trunk should be the most stable part of your source tree. It should always be in sync with the code you have running in your production environment. This way, you always have a starting point to address any issues pop-up in production.
Start your source tree off by creating a folder in TFS Source Control Explorer that will be your trunk. Once the folder is created convert it to a branch by right clicking on it, expanding the Branching and Merging option and clicking Convert to Branch. Viola! Your trunk is created. Right click on it and check it in to TFS source control.
At this point you have a container for your production source code. If you already have some add it to the trunk by right clicking on it and choosing Add Items to Folder. Once you’ve added any source code you have check that in by right clicking on the Trunk again choosing Check in Pending Changes.
Done. You now either have an empty container ready to receive source code or a Trunk that is a snapshot of the code you currently have running in production.
Now comes the fun part. You are never going to directly edit code in the Trunk again. That’s right. Never. Remember what I said about the trunk being the most stable part of the source tree? If you start hacking on it by making code changes within it you’re going to eventually weaken if not kill the stability of the trunk.
Right now you are asking so how am I going to get new code into production? Well, even though you are not editing in the trunk directly it doesn’t mean the trunk doesn’t ever change. All new code will eventually flow through the trunk and out into production. So how does that happen? With branches.
Branches are the new growth of your source tree. They shoot off of the trunk in multiple directions letting you explore any new approaches you want. Some will only ever amount to experiments that you ultimately abandon. These will never make it into the trunk or into production.
Others will become feature sets that you do want to move forward with. These you will develop, test, verify and then eventually deploy.
To create a branch, right click on the trunk in TFS Source Control Explorer. Expand the Branching and Merging option and click Branch. This will present you with a window to name and describe the new branch. Name the branch according to the conventions of your organization and enter a thoughtful description that will be helpful six months from now at 2:00 am after seventy two hours of no sleep and three pots of black coffee.
Click the branch button. Verify that you actually do want to create the branch and there you are. Your new branch is created and ready for you to start developing the latest and greatest features for your application.
But hold on. There’s an important piece missing from the picture. Once a branch has been developed and tested and you’re ready to move it to production how does it get there? You never deploy to production from a branch. Deployments always come via the trunk. So how do the changes in a branch make it back to the trunk?
Merges are the secret to allowing you to keep your trunk stable while at the same time getting your branch changes deployed to production. At this point the trunk represents a different version of the application than the one you want to deploy to production. You’ve made changes. Maybe you’ve added new things and maybe you’ve even deleted a few things. How do you reconcile that with the trunk? You do it with a merge.
In TFS Source Control Explorer, right click on your branch, expand the Branching and Merging option and click merge. If your changes are not too complex you may not see anything more than a message telling you the merge was complete. However, it is likely that you will be prompted to make some decisions about how you would like the changes applied.
This typically looks like a split window showing you the changes you have made to the code side by side with what exists in source control for the trunk. You will need to step through these comparisons and decide which ones to keep. Once you do that your merge is complete and now the trunk is up to. Date with the changes you made in your branch.
Deploy the new version of the trunk to production and everything is once again in sync.
This has described a very simple scenario for source tree organization. Other factors may complicate things a bit for you, like other developers working on features branched from the same trunk. These scenarios require a bit more planning but still do not deviate too far from what has been discussed here. Better yet you can build on this tree structure to accommodate them. I will cover these factors in a later post but for now, rest assured that this is a great way to get started.
Question: What source tree problems have you encountered?