I know that lots of organizations are still using old-expensive-counterproductive configurationmanagementsystems (ClearCase,VSS, etc.). I understand the fear that prevents many ofthem frommoving to a decentSCM(Subversion,Mercurial, etc.). I’ll try to tell a story about that kind of migration, which might alleviate thefear.

A huge company, with 40,000+ software developers, with 10+ years history using ClearCase, wants tomigrate toSubversion, because ofSVN’s encouragement to atomic commit andoptimisticlocking. The movement is still ongoing. Every single pace involves at least one delivery team,normally with100+ programmers in it.

The movement must be as seamless as possible, because people are pushed to meet their next milestone.For acodebase sized over 4GB, we made the migration in a week:

• Monday
  • Export the existing codebase and check it intoSVN AS-IS—it’stime consuming so you have enough time for following items.
  • Send mail to everyone to inform the migration plan, ask them to installSVNclientif they haven’t.
  • Make sure everyone can access newSVNrepository.

• Tuesday
  • Check out the codebase fromSVNand build it, to make sure you are not breaking anything—that’s why youreally shouldmigrateAFTERyou have a decent build script.
  • Compose a shell script to synchronize from ClearCase local view toSVNworking copy. Synchronize frequently and build every time.

• Wednesday
  • Clean the codebase: legacy repositories often have lots of garbage (temp files, compiledbinaries,etc.) checked in, it’s now a chance to do some clearance, delete and ignore themfromSCM. Just don’t break the build.
  • Installcontinuous integrationinstance for the codebase inSVN.
  • Synchronize and build frequently. Ask people to fix build if it breaks.

• Thursday
  • Send mail to everyone, ask them to commit any modifications by the end of day, and tellthem “there’sanSVNtraining tomorrow morning”.
  • Keep doing clearance. Synchronize and build frequently.

• Friday
  • Disable write-access to ClearCase.
  • Training: Configuration Management &SVN. People need tounderstandsomeSCMprinciples to make a better use ofSVN—at least not tomess up thecodebase with garbage again.
  • At the same time, synchronize a last time, build, check in.
  • Package your working copy and upload it to a shared directory: it’s much faster tocopy andunzip, than checking out from the repository. Mail everyone about how to get a workingcopy and makefirst commit.
  • Publish your CI to the team. It’s now the team’s CI.

That’s it. Now your team is onSVN.