Branch-per-version Workflow in TFS

This is cross-posted from here.

Hi, I am having trouble with the workflows involved in a branch-per-version (release) scenario. I have a Subversion background, so my understanding of how TFS works may be ‘biased’ towards Subversion.

Our policy involves branching-per-version and branching-per-feature. Typically, changes will be developed in a feature branch (whether new features, bugs etc). Once complete, these feature branches will be merged into trunk (mainline) and the branch deleted. For a deployment, the changes made in each branch will be merged onto the last deployed version. This ‘patched’ version will then be branched as the new version. This requires that the new version branch be created from the workspace, and not from a latest version in the repository. When we try perform a branch from the workspace version, the opposite of what we expect occurs.

Let’s assume that I have a release branch version-1.0.0. A production bug is reported, and the bug is fixed in mainline as changeset 25. I now want to apply changeset to version 1.0.0 to create version 1.0.1. So I open my workspace copy of the version-1.0.0 branch and perform a merge of mainline changeset 25 onto the branch. Now, the change is correctly applied to my workspace copy, and the relvant files have been changed and are checked out. Then, in the source control explorer, I branch the version-1.0.0 branch to a new branch caleld version-1.0.1, and I choose to branch it from the workspace. When I check this change in, what happens is that changeset 25 is applied to the version-1.0.0 branch, and NOT to the version-1.0.1 branch as expected. That is, version-1.0.1 looks like version-1.0.0 before the change, and version-1.0.0 contains the change.

The same happens if I create a label from the merged workspace copy.

Effectively what we’re trying to achieve is simulate a ‘tag’ in Subversion (which are just branches anyway with some extra semantics).

I’d like some guidance on how to apply ‘hotfixes’ to a version branch to create a new version branch, and not change the ‘original’ or baseline version.


2 thoughts on “Branch-per-version Workflow in TFS

  1. Disclaimer: I have zero experience with TFS.

    Based on my experience with Subversion and other Version Control Systems the more complex the source control policies the more difficult it becomes to navigate versioning considerations. This also influences the teams ability to build momentum without fighting infrastructure.

    I try to be as agile as possible – even here in my source control policies and apply the principle of “last responsible moment” to if and when I should branch.

    It is exception rather than the norm for me to create feature branches. If it is really a feature (i.e. not a bug) then it is more than likely done on the mainline.

    On every versioned release a tag is created (as you know a simple named revision). If a bug is reported against that version, a branch is created at that point in time from the associated tag and the bug is fixed on the branch. You then merge the changes (if and more than often required) back into the mainline to prevent any regression.

    So the simple policy I follow is branch only when it would irresponsible not to do so and aim to always merge towards the mainline.

    Keep up the blog posts – they are always an interesting read.

    1. Hi Ahmed, thanks for the comments.
      I agree with your comments, but there are some friction points with this strategy when working with TFS, purely from limitations of TFS. For example, in SVN if a tag is based on ‘trunk’ and you create a hotfix in a branch of the tag, you can merge that hotfix branch straight into trunk. This can’t be done in TFS because you can only merge between direct children and parents.

      Another friction point is that the support for the (semantic) concept of tags is realy weak in TFS.

      I’ve also started to realise that a lot of my strategy is based on not trusting the stability of trunk – which leads to the need to branch-per-feature and cherry-pick changes to promote to testing and production envrironments. This is probably due to not trusting my team members, but also due to the lack of any kind of review process in my team.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s