Version Control Guidelines

Written by Mitch Denny

The purpose of this knowledge base article is to briefly outline the version control standards for code that is checked into the development environment. It is expected that build masters, scrum masters and sustained engineering team members will ensure this standard is adhered to.

Basic Layout

The root directory of each team project is typically in the form:

    $/[Team Project]

Where [Team Project] is the name of the team project. This standard dictates that the immediate structure underneath that root level is as follows:

    $/[Team Project]

        /Trunk

        /Branches

        /Releases

The purpose of the Trunk folder is to maintain the mainline of source code development. Typically an agile development team would spend most of their time checking code into folders beneath this location. The Branches folder is to be used when the development team decides it needs to isolate some development activities. Valid reasons for creating a branch are:

• Isolating development of a feature that may impact productivity of other developers.
• Performing some exploritory development which may be discarded such as attempting to upgrade to a new framework version.
• When you are working in feature crews which need isolation.

The Releases folder is used to create branches of code as it is delivered to customers. For example, if an official BETA, RC or RTM release is produced for the product, a branch can be created to support hotfixing if necessary. Remember that this can be done retrospectively from a specific changeset. Release branches can quickly diverge from the Trunk so merging hotfixes should be done with great care to ensure that builds and tests still pass and regressions are not introduced through automatic merge activities.

Team Foundation Server 2010 Branching Features

With the introduction of Team Foundation Server 2010 branches become first class citizens within the version control store. It is strongly advised that teams right mouse click on the Trunk folder and select 'Convert Branch' within source control explorer. Doing this will open up the changeset tracking features within Visual Studio 2010.

Branch/Release Folders

Within the branch and release folders, each branch is represented as a seperate folder. For example, a feature branch would would actually be located at the following path (example for a feature called FeatureA):

    $/[Team Project]/Branches/FeatureA

Structure within Branches

So far this knowledge base article has only mentioned the overall structure in terms of branching. Within each branch (Trunk included) source code should be layed out in the following way:

    $/[Team Project]/Trunk/

        /SolutionDir1

             SolutionDir1.sln

            /ProjectDirA

                 ProjectDirA.csproj

            /ProjectDirB

                 ProjectDirB.csproj

            /ProjectDirC

                 ProjectDirC.csproj

        /SolutionDir2

             SolutionDir2.sln

            /ProjectDirD

                 ProjectDirD.csproj

            /ProjectDirE

                 ProjectDirE.csproj

            /ProjectDirF

                 ProjectDirF.csproj

Common Mistakes

The reason this article exists is that teams often make mistakes when laying out their version control. One such common mistake is locating the *.sln file immediately under the Trunk folder within the team project. This approach does not allow for the gradual evolution of the code base where additional solutions might be created. When this situation occurs it is the responsibility of the Scrum Master, Build Master or sustained engineering team to ensure the problem is rectified and the appropriate build definitions are updated.