Synching TFS with other Source Control systems

josealmeida — Wed, 17 Sep 2008 15:33:42 GMT

Many of us in the field have come across heterogeneous source control environments within the same organization. Some organizations, having multiple source control systems, wish to have some way of synchronizing TFS with their other systems. I've seen this when development teams who are used to the Microsoft development tools tend to prefer Team Foundation Sever and sometimes operations teams, who are responsible for deploying and maintaining the software produced internally maintain a portfolio of versions of the software in other control systems, like ClearCase for instance.

The TFS Migration and Synchronization Toolkit allows developers to build custom tools that provide migration and synchronization capabilities with other version control systems.

There's a new version of this toolkit available in Codeplex. This release includes enhanced support for the migration of branches and merges.

Branching Strategies

josealmeida — Thu, 10 Jan 2008 21:48:00 GMT

Under Software Configuration Management, branching and merging are common features that help maintain stable code bases and scale the development effort by synchronizing parallel development. However, depending on the size of your product, the size of your team, your isolation requirements and your development cycle, parallel development can become quite overwhelming, so it's very important to define a good strategy for branching and merging that meets your needs. This isn't always straightforward, so here are a couple of guidelines I usually use to tackle this issue.

The first thing I try to find out are the isolation requirements for parallel development, how many development teams there are and what are the stabilization protocols (how many quality gates there are and how many different test environments there are where these gates are checked).

Having this information helps me to define the logical structure for the branching strategy as well as the physical source control structure to support it.

One thing I always have to look out for, is to make sure that the logical structure is applicable to the physical structure. For this I usually define a set of use cases that act as a model that I "run" on both the physical and logical structures to check if they are supported.

Here are a couple of scenarios I usually contemplate:

Fixes
Release Stabilization
Code Promotion

I try to check all of these scenarios, considering that a mix (or all) of them might occur simultaneously. Here's a possible scenario I try to work out:

"Imagine there's a team working on a new release of feature A, part of another team is working on a fix of a previously released version of their feature (feature B) while the rest of the team is working on the next version. In the meanwhile, a third team is required to release feature C to a new test environment for functional testing by end-users."

Some questions that I might ask for this scenario:

How many teams/features are there?
What should the physical structure of my source control repository be?
How many independent branches do I need to make this scenario valid?

The Branching Guidance by the P&P team is an excellent place for different approaches to these questions and many more.

So, what do I really look out for when defining a branching strategy?

Good Logical Structure
Good Physical Structure
Make sure the logical structure is applicable to the physical structure
Run a model on both the logical and physical structures.

Jose's Blog : Source Control

Synching TFS with other Source Control systems

Branching Strategies