TFS - Branching

TFS - Branching

Josh Doolan | 28/10/2011

So you are at that point where your application is at a somewhat stable state and you think it is a good idea to start versioning your releases within sources control (which is a good idea).

So the basic repository structure for this type of versioning setup is generally:

Trunk: The repository of the current build

Tags: The set of releases that have become of the the trunk

Branches: The side developments to take the solution to next build.

The idea behind splitting these up in such a fashion is really only for 2 main reason: 

1.  To always have a central working copy (trunk) – that isn’t edited directly; is only updated through merges form the branch(explained later)
2. To have a record of previous/builds and releases (for roll back and historical purposes)

Setting this up in TFS is really a snack – Right click on your current working solution folder, which will now become the trunk – and select ->Branching and Merging - > Branch

Store the branch solution under a “Branch folder” with your desired naming convention i.e branch1 or branch-CurrentWorkReq …

After that, continue the same process in creating a tag folder and tag your current build with your desired naming convention i.e build 1.0 or release 2 or my case just a date stamp.

The resultant folder structure is as follows:

If you are at the point where you are happy with your branched dev and you would like to add it to the trunk for a tagged release, simply right click on the branch -> branching and merging - > merge. Then select your trunk solution and walk through the wizard. This will effectively update the trunk.

So then just to recap  - the trunk copy is always the current working copy of the current release(live).

Simple, safe, organised and effective.

tags: Web Development