Changing Source Control as a Kaizen Event

I often have opportunities to work with organizations in transition to Team Foundation Server for their source control solution. Most large organizations (and many smaller ones) look for a migration route for their source code that allows them to retain history and their current merge/branching model. In heavily regulated environments, this is often a fundamental requirement, in fact. Accordingly, there are many packaged conversion tools out there to serve this need. There are Team System SCC conversion utilities for IBM’s Clear Case, VSS, SVN, StarTeam, CVS, Perforce, and others. The mere existence of these tools lets me know that migrating source code in the same structure it previously existed is considered “good” by many.

My default recommendation is to do a clean, fresh, manual import rather than to migrate source code with existing structure. I have several reasons for this including:

• Code migration is more complicated and it will take longer (cost more).
• Tools have flaws. Everything may not turn out the way you think it will when you have been branching and labeling in that old system for 6 years.
• The majority of code file comparisons occur at the tail end of source control. Very rarely is a comparison made on a code file in SCC older than 60 days.
• The reason you want to retain history is to blame that guy.
• Your branching model was probably over complicated anyway.
• History for auditing purposes can be found in the old system, kept online and read-only for a year or two if necessary.

But the number one reason I don’t want to bring the source code over in the same model is because this is a golden opportunity to improve.

It amazes me that the structure of a SCC system reflects the nature of the organization that created it. I have learned, however, that it does. Are management decisions hectic? Are releases going out buggy? Look for lots of deep branching structures. Are developers working in separate branches on the same release? Look for lots of cherry pick merges.

It is a fundamentally healthy exercise to pull a large pile of source code out of the old system and bring it into the new one one project at a time, ensuring that each one is self contained. In other words, break the dependencies between projects and all of those weird references to resources outside the boundary of the solution.

It comes down to this, why are you making this tooling change in the first place? Odds are that the tool change is being done because the team wants things to get better. Whether you are moving to Team System, SVN, or something else, you are moving to a new system to make an improvement. Given the desire to improve, take advantage of the opportunity to actually make things better rather than to persist old dysfunctions into a shiny new tool.

As a manager of development teams myself, I found great value in migrating source control every 2 years or so, just to cause such a spring cleaning event.

And the number one thing you can do to make this a true Kaizen event? Ensure that each and every project (that is, every *.*proj file) gets build built via a CI build before adding another project to the system.