Paul Dowman

When I was moving EC2 on Rails to Git I found several posts that explained how to convert a repo from svn to Git. But none of them included converting your svn tags to Git tags, so here’s yet another how-to guide. (Git experts please comment if I’m doing anything dumb.)

1. Install Git

First, you’ll need Git installed with git-svn included (git-svn will actually allow you to push changes back to the original Subversion repository, but for our purposes we’re assuming that this is a one-time conversion).

If you’re using OS X you should already be using MacPorts, so just do:

prompt> sudo port install git-core +svn

Or, on Ubuntu or Debian Linux:

prompt> sudo apt-get install git-svn

2. Create the authors file

Next, create a text file that maps Subversion committers to Git authors so the names and email addresses will be correct in the history. Save it as authors.txt:

pdowman = Paul Dowman <paul@hellospambot.com>
svnuser2 = Another User <anotheruser@whatever.com>

3. Clone the repository

Now run the command that will import your svn repo into a local Git repo. I’m assuming your svn repo had the standard layout of /trunk, /tags and /branches.

prompt> git svn clone --no-metadata -A authors.txt -t tags -b branches -T trunk <your_svn_url>

Now running git log should show all your commit history with the correct authors.

4. Convert branches to tags

There’s one more thing. All your tags are now remote branches, not tags, in your Git repo. So you’ll need to convert them manually (or write a script to do it if you have a lot, I’ll leave that as an exercise for the reader). For each Subversion tag (i.e. Git remote branch) you’ll add it as a Git tag, then delete the remote branch. List them with:

prompt> git branch -r

Then for each tag listed do:

prompt> git tag tagname tags/tagname^
prompt> git branch -r -d tags/tagname

You now have a local Git repository with all your history and tags. If you don’t need to share it with anyone else then you’re done.

5. Push to a public repo (optional)

If you want to publish to a public repository (for example Github), you’ll need to add it as a remote repo and then push to it.

prompt> git remote add origin git@github.com:userid/project.git
prompt> git push origin master

You next stop should probably be the Git tutorial for Subversion users. Enjoy!

I’ve moved EC2 on Rails from Subversion to Git. It’s hosted on Github at pauldowman/ec2onrails.

Most Ruby developers are familiar with Git by now. (If you’re not: it’s a distributed version control system that was created in 2005 by Linus Torvalds for Linux kernel development). Within the last year almost every Ruby-based open-source project has switched to Git (including Rails itself). And in fact they’re almost all hosted on Github!

At first I found it funny that even though they were moving to a distributed version control system, everyone decided to keep their repositories in the exact same place. Being distributed, a Git repository doesn’t need to be hosted unless you’re sharing it. You can publish it easily on any web server, and RubyForge (which has always been the most popular place to host Ruby projects) supports git.

But after playing with it a bit I can see why everyone is choosing Github. For one thing they got the project hosting part right, with a simple clean UI and cool features like an API and hooks for all kinds of services.

But the really cool thing about Github is that it provides a social environment. You can watch projects as you’d expect, but you can also follow people, send them messages, and easily send them pull requests (to integrate changes you’ve made). It’s great for discovering interesting and new projects: just follow friends and people whose work you like to see what they’re watching, creating and forking.

Now that EC2 on Rails is on Github it’s more likely that other people will want to build it themselves so I’ll try to make that easier with a one-step script at the root of the project. Feel free to fork it, implement changes and send me patches or pull requests.

And find me on Github!

I released version 0.9.9 of EC2 on Rails a few weeks ago and announced it on the mailing list but forgot to mention it here. The main change was switching to version 8.04 (”Hardy”) of Ubuntu. See the change log for full details.

UPDATE: it’s 0.9.8.1 now, there was a small update to the RubyGem. The new gem uses the same AMI’s.

EC2 on Rails version 0.9.8 is now available (or will be in a few hours when the RubyForge servers are synced). This is a recommended update for everyone.

It includes some major new features:

• monit monitoring daemon: monitors mysqld, apache, memcached, mongrels, system load and free drive space
• incremental MySQL backup (important for large databases)
• Apache SSL support
• a local Postfix SMTP server enabled by default

And most importantly this fixes the problem with broken Ubuntu package updates which was caused by a missing repository in the list of repositories.

As I mentioned yesterday, the base image is now built using Eric Hammond’s EC2 Ubuntu script.

Also, there are major new features such as incremental MySQL backup (important for large databases), Apache SSL support, and a local Postfix SMTP server enabled by default.

My priorities now are:

1. Release an update based on Ubuntu 8.04 Hardy (this version is still using Ubuntu 7.10 Gutsy because I wanted to provide a reliable update as quickly as possible due to bug #20040. But now that the base image is built with Eric Hammond’s script it should be easy to update to Hardy.)
2. Create complete documentation.
3. Release a 100% bug-free version 1.0 with the current feature-set. Please help by reporting any bugs you find, either using the RubyForge bug tracker or by email.

The point of EC2 on Rails is to save other people from duplicating the effort of building and configuring a Rails server on EC2. When I started it there were no other public Ubuntu server image projects so I had to start from scratch. I had to write a build script to build an Ubuntu image, patch the Amazon AMI tools to work on Ubuntu, etc., before I could even begin to create the Rails-specific stuff. And every 6 months there’s a new version of Ubuntu and I have to do at least some of that over again.

But in the meantime Eric Hammond has created an excellent Ubuntu AMI base install project, it has all the necessary features like installing the AMI tools, getting the public keys on first boot so that you can log in with your EC2 account’s private key, regenerating the ssh host keys on first boot, etc. And it has some cool new features like the ability to give an instance an arbitrary script on startup using EC2’s “user-supplied instance data“. And, it has an active community.

So why would I duplicate that effort?! I’d rather concentrate on improving the Rails-specific features, so I’ve adapted my build script to be run from Eric’s. And by “adapted”, I mean “took out tons of stuff that I no longer need to care about”! And when I want to make any improvements that aren’t Rails-specific, I can contribute them to Eric’s project where they’ll benefit more people.

If you’re building your own custom AMI, I highly recommend using Eric’s base install script. You’ll end up with a solid base for your image with way less work, and it has a hook to easily include your own build script to customize the build.

Version 0.9.8 of EC2 on Rails uses Eric’s script for the base install, and it will be released in a couple of days (I’m using it in production already).

Seriously, why reinvent the wheel? You gotta love open source!