Migrating To A Decent SCM
September 1st, 2010
I know that lots of organizations are still using old-expensive-counterproductive configuration management systems (ClearCase, VSS, etc.). I understand the fear that prevents many of them from moving to a decent SCM (Subversion, Mercurial , etc.). I’ll try to tell a story about that kind of migration, which might alleviate the fear.
A huge company, with 40,000+ software developers, with 10+ years history using ClearCase, wants to migrate to Subversion, because of SVN’s encouragement to atomic commit and optimistic locking. The movement is still ongoing. Every single pace involves at least one delivery team, normally with 100+ programmers in it.
The movement must be as seamless as possible, because people are pushed to meet their next milestone. For a codebase sized over 4GB, we made the migration in a week:
- Monday
- Export the existing codebase and check it into SVN AS-IS—it’s time consuming so you have enough time for following items.
- Send mail to everyone to inform the migration plan, ask them to install SVN client if they haven’t.
- Make sure everyone can access new SVN repository.
- Tuesday
- Check out the codebase from SVN and build it, to make sure you are not breaking anything—that’s why you really should migrate AFTER you have a decent build script.
- Compose a shell script to synchronize from ClearCase local view to SVN working copy. Synchronize frequently and build every time.
- Wednesday
- Clean the codebase: legacy repositories often have lots of garbage (temp files, compiled binaries, etc.) checked in, it’s now a chance to do some clearance, delete and ignore them from SCM. Just don’t break the build.
- Install continuous integration instance for the codebase in SVN.
- 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 tell them “there’s an SVN training tomorrow morning”.
- Keep doing clearance. Synchronize and build frequently.
- Friday
- Disable write-access to ClearCase.
- Training: Configuration Management & SVN. People need to understand some SCM principles to make a better use of SVN—at least not to mess up the codebase 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 to copy and unzip, than checking out from the repository. Mail everyone about how to get a working copy and make first commit.
- Publish your CI to the team. It’s now the team’s CI.
That’s it. Now your team is on SVN.
