Posts Tagged ‘ migration ’

Migrating from SVN to GitHub

Good time to migrate

For long time, we’ve been using SVN (svn+ssh) to serve our versioning needs… A centralized repository with development/staging/production branches worked relatively well for us. Managing SVN  on our own is ok when the team is static and when the no of changes is not overwhelming.

Recently though, we are planning to get  other teams to work with us, hence there will be more work related to managing users, branches etc. Therefore, it’s the perfect time to move to github.

Creating an organization’s github account

Creating a new organization requires using a new user account – I didn’t find a way to add a new organization by using my current github account. So I created a dummy github (using my company email) and added my existing github user to the list of organization members. So far so good.

Then I had to upgrade the subscription level to be able to create a private repo – would be great if one small private repo could have been created without providing credit card no – not a big deal though.

Migration

There are some tools out there that are supposed to be able to automatically migrate an svn repo to git. I tried svn2git first, but decided to drop the old svn structure, and use the opportunity to cleanup and improve our current branch structure. I got inspired by “A successful git branch model“. So to start with the migration was as simple as these steps (I can’t embed code snippets in wordpress.com – will have to migrate to self-hosted wordpress.org soon):

  1. create .gitignore
  2. git init
  3. git add app test vendor config public scripts …
  4. git add -f .gitignore  (I want the gitignore to be stored in the project and shared with other users)
  5. git commit -m “My first commit”
  6. If you haven’t created .gitignore before adding the files, you might find lots of .svn/entries in git. Here is how to remove them: find . -type d -name ‘.svn’ -exec git rm -rf {} \;
  7. git remote add origin git@github.com:my_git_user/repo.git
  8.  git push -u origin master
Now we have our code on github.

Getting (auto) Deployment to Work

To get my deployment to work, first I had to give access to staging environment’s users. It’s relatively easy done by uploading the public key to the github (Account Setting/SSH Public Keys) and to add the following code to ~/.ssh/config  (make sure to put the private key there – by mistake I first added the public key and it failed). You can test the connection by running  ssh -vv git@github.com.

New branch structure

The successful git branch model is great,  but now I need to get it working and this capistrano recipe is a good starting point. Instead of branching we use tagging. The local workflow is as simple as:

  1. git checkout -b “changeset1”
  2. <add and change code>
  3. git add <list of files>
  4. git commit -m “New featur in changeset1”
Then to push changes to shared repo we need to: switch to master branch(1), pull the changes(2), merge our change branch(3) and push the changes back(4)
  1. git checkout master
  2. git pull
  3. git merge changeset1
  4. git push
Using capistrano though, we can push the changes to the staging server and to github in one command:
  1. capistrano staging deploy # it creates tag staging-2011.06.13.1
  2. capistrano production deploy -s tag=staging-2011.06.13.1
capistrano deploy task takes care of tagging the master tag, pushing it to github, and deploying to staging server.
Deploying to production uses the tagged version. Thats it.

Summary

In a few hours I managed to setup our company gtihub account, migrate our code from svn to github, prepare new workflow and update our scripts to use it. We have now a repository managed by somebode else, workflow that is more flexible and extensible. I can start focusing on improving the working tasks …