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:
- 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.
- 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.
- 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.
- 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.
- 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.