Migrating from CVS to Git

Submitted by Barrett on Sat, 11/03/2012 - 20:03
Migrating from CVS to Git

One of the initiatives begun since I came on board at USP is to convert the team from using CVS for version control to using Git. CVS was performing adequately in most respects, but the leadership recognized that Git is the de facto industry standard these days and that, beyond the technical benefits of moving to Git, there was value in keeping up with the standards of the industry and the Drupal community. The question, then, was how to best accomplish the change.

The first course we investigated was using git cvsimport. Our hope was that this would allow us to move our entire repository history into CVS. When we started testing it out, though, we found the results to be unclear and were not certain that everything was reflected in the resulting branches. Based on the uncertainty, we decided instead to do a more static conversion and leave the pre-Git commit history in CVS.

Because of the business needs we had to support, we decided on a branching strategy of using three long running branches; one for each of our development, testing, and production environments. Because there was no point in time when all three environments were in sync, each branch needed to be initialized independently. We also wanted to minimize the downtime, particularly on production. We decided to essentially wrap CVS in Git and that our process would be:

  1. Create an empty repository on the origin and add a .gitignore file to take care of the files we didn't need to track (like the CVS directories and the .# files CVS uses for tracking.
  2. Add files from the production web server by:
    1. running git init on the production server
    2. adding the repository created using git remote add
    3. checking out the master branch to pull down the .gitignore file we created
    4. adding and commiting all the files from production to the master branch of the repository
  3. Set up the dev and test branches by:
    1. moving all the files from the environment to another location
    2. cloning the repository onto the web server
    3. creating and checking out a new environment branch (i.e., dev on the dev server or test on the test server)
    4. moving the original files back onto the web server
    5. adding and committing the changes to the environment branch

The end result of this process was that we had a working Git repo and still have access to all the CVS history by running CVS on the same file set. All that with no downtime on production at all and only about thirty minutes of downtime on each of the dev and test environments (including a lot of running git status to double check that everything was as we expected).

Barrett Sat, 11/03/2012 - 20:03

Tags