August 4, 2009

Baseline and Branch Import (BBI) - A Migration Strategy

E-Commerce
Migration
we-need-just-a-few-birds-for-this-migration!
We need just a few birds for this migration!

Want to migrate to Perforce?  Here's a migration lightweight strategy to consider.  Rather than endeavoring to bring forward all those historical details, how about bringing forward just key points in the history?  Wouldn't it be great to be able to visualize and diff key points in the evolution of your software through Perforce eyes, using the Revision Graph and Time Lapse view?

The "baseline and branch import" (BBI) strategy is based on getting the optimal benefit from a migration for the least amount of work. "Detailed history import" (DHI) migration tools, by contrast, try to get all the details.  There are a laundry list of technical challenges and caveats to DHI, which translate into budget and schedule risks for migration projects.  Detailed history imports may be the right solution if your requirements truly demand detailed history.  But don't assume you need history -- ask yourself if it's worth the effort.

To be sure, if you're doing a DHI migration on a well-trodden path using proven tools, like going from CVS or Subversion to Perforce, you're likely to have a good experience.  But even those proven tools can choke on some data sets.

With the BBI approach, you replay key points in your history into Perforce, leaving the details behind.  Say you released v2.0 of your product, and then in parallel you developed newer releases while delivering patches on the released version.  You can draw a diagram like this one, and then import just the history illustrated -- leaving behind the hundreds or thousands of checkin comments that actually occurred between the baselines represented by dots on the diagram.  You would have the file sets and contents of files as they were at the select baselines (the dots), keeping just the "interesting history".

figure-2:-branch-diagram-illustrating-history

You can get a bit more sophisticated.  With BBI, you can tell Perforce that changes made up to patch 'p2' on the v2.0 release maintenance branch (the line at the top of the diagram) have already been merged in with the new development efforts, but the remaining patches haven't.  The BBI approach allows you to record the completion of that merge done in your legacy SCM system, and then you can pick up from there once you're in Perforce.  Cool, eh?

Rumor has it there will be a KB article with more detail on this approach after a while ...