Process template
The version control part of our process template is the same as both the MSF for Agile and the Microsoft Scrum templates.
Multiple check-out is enabled, because there is no reason to disabled it. Any conflicts can easily be resolved using the tools available in Visual Studio, most of the time even automatically. In some instances however, like when refactoring a lot of code, you may consider checking out the affected files with a check out lock. This is still possible with multiple checkouts enabled, but you need to check-out the file(s) manually and select the ‘Check Out’ Lock type.
Get latest on check-out is disabled, because I want control over when the latest version is downloaded. I get the latest version before I start changing any code, but I don’t want any changes on the server to interfere with my coding work while I’m coding. I’d rather resolve any issues once, during check-in, instead of every time I check out a file. Of course, if I need changes made by others, I will get the latest changes, but I’ll decide when.
I didn’t define any check-in policies. Of course everybody should provide comments, associate with work items, run code analysis and make sure the code builds before check-in. But we’ve decided not to make them policies and let them prevent from checking in. One reason is that, although a policy can check if certain information (like comments or a work item) is provided, a policy can’t check if it is meaningful. So these things will be monitored and if a team member is not providing the required information, we will explain why it is important and help to provide the right and meaningful information.
I also didn’t change the check-in notes. I’ve not used them yet and don’t expect to use them in a scrum project, but decided to leave them in.
The above mentioned settings are the default in the process template, but can of course be changed in a specific team project if there is a need to do so. And if there is a very good reason to do so, we can even change the process template :-).
Branching and merging
Branching and merging is an important part of version control, but not a part of the process template. Based on the Branching guide from the ALM Rangers (http://tfsbranchingguideiii.codeplex.com/), we have decided upon a strategy that will allow us to start simple, grow as we need and even take different approaches if required. Below are the basic choices, where the simplest workable solution is the best.
Always start with a Main folder and make it a branch. For very small projects, this could be the branch where development takes place. Only if maintenance is needed on a released version, a new release branch is created using the label that was created during the build of that particular version.
Create separate development branches for multiple teams, or small projects if working in the Main branch is making that branch unstable. Always create a container folder that holds all the development branches, even if there is (currently) only one development branch. Forward and reverse integration with the Main branch is done as much as possible, to minimize the amount and complexity of conflicts.
Release branches, as already mentioned, but also branches for hotfixes, service packs and other maintenance work are only created when necessary. Such branches can easily be created using the label of the build related to the version requiring maintenance. The complexity of the total branch structure really depends on the project and we use the branching guide as a guideline.