Keeping TFS Version Control in synch

Within the span of 4 years a single company I worked for used 5 different version control products.  VSS, PVCS, CVS, ClearCase and Perforce.  Change happens.  And anyone who has gone through a major version control server change knows that sometimes change hurts.

 

I’d like to talk about some of the barriers to change that I’m hearing from friends outside of Microsoft who are looking at TFS.

 

1) Management wants to have a single team perform a pilot project before they will get everyone on board.  How do we allow a single team to use it while everyone else is still using our current system?  And can we do this without losing history if we decide not to adopt TFS?

2) The build systems and processes will need to be ported to support the new system.  This will take time and we aren’t ready to make a move to Team Build – we have too much invested in our systems.  We can’t migrate until that is done but we really can’t do it until we’ve committed to migrating.

3) We want to start using the system once we’re more comfortable that it can support our development practices or team size but in there is a catch 22.  How do we know we’re comfortable until we’ve used it if we won’t use it until we’re comfortable with it?

 

Do you have other concerns?

 

Something I’ve been spending a lot of timing thinking about lately is how to resolve some of these problems.

 

What I think these problems boil down to is:

 

“We need to be able to have development occurring concurrently in two disparate version control systems and have a mechanism to keep those two systems synchronized (in effectively real-time).”

 

That mechanism would address concern #1 by allowing a single team to pilot TFS while the rest of the team works in the original system.  Both systems would be kept in synch giving each team an identical view into the code.

 

It would address #2 by allowing development to occur in TFS while builds could continue to run out of the original system until there was adequate time to port and test the TFS build process (or to setup a Team Build process)

 

And #3 by allowing development to occur in the original system and as it does the TFS server is kept in synch.  This will enable the team to evaluate whether or not TFS was able to satisfy their requirements without forcing even a single developer to move to TFS.

 

In all three cases when you are done you have a TFS server that has some history in it,  that should make the final transition to TFS less painful, and you have an original system with complete history so you are no worse off than when you began even if you decide to not adopt TFS.

 

Without getting into implementation discussions I’d like to know what people think of this idea. 

 

Would a service like this help lower barriers to adoption (or at least a pilot project)?

Comments

• Anonymous
  February 02, 2006
  John Lawrence alerts us to a possible error when upgrading to Team Foundation RC.
  
  Martin Woodward...
• Anonymous
  February 21, 2006
  We borrowed Robert Horvick from another team at Microsoft last year (Where I've been ... Team Foundation...
• Anonymous
  February 22, 2006
  Definately this would help adoption.  However, one thing that is just as important, or maybe more so, to keep in sync for the same reasons is the work item tracking being kept in sync with bug tracking tools, like FogBugz.  
• Anonymous
  February 22, 2006
  Patrick,
  
  I agree.  Version Control mirroring is only a part of the story.  Let me change the question slightly... would it be more beneficial to have mirroring services for a small number of popular systems released, or would it be more valuable to have a source code framework released which made creating one for any system more approachable?
  
  Robert.