Mephisto: Change from SVN to Git April 19th
The fine folks over at ENTP/ActiveReload have released version 0.8 of Mephisto, the Rails application that powers this site. With this new release, they, as everyone these days, have actively shifted the remaining bits and pieces of Mephisto’s development from Subversion to Git. (And its main repository is hosted at Github, where else.)
I hardly remember ever installing Mephisto from a tarball. I always used to track its Subversion trunk for the 3 blogs I run, which made upgrading as easy as svn up && rake db:migrate RAILS_ENV=production most of the time. Well, that was then and this is now. Looking at this recent shift to Git, I wanted to convert my blogs to the new Git repository without excessively messing with whatever I did to my local installation (quickly approaching my 30s, I might not even recall most of what I did). I was pretty certain, however, that I did not have massive local modifications. If I had, this approach might’ve been a little simplistic.
Here’s what I did.
Initializing
Starting out, you need to create a local Git repository within your local blog installation, which is as simple as:
$ cd /your/blog
$ git init
Initialized empty Git repository in .git/
The next step is to setup technoweenie’s master repository on Github as a remote to your local repository and fetch what’s currently in there.
$ git remote add technoweenie git://github.com/technoweenie/mephisto.git
$ git fetch technoweenie
remote: Generating pack...
...
This will fetch both the master branch and all branches technoweenie might’ve created. (This includes, for example, a branch that holds the current 0.8 release, if you don’t dare to ride the edge of Mephisto’s development.)
Merging
At this point we need to merge one of the branches we just fetched into your local (totally empty, for what it’s worth) repository. (I’ve decided to stay on the master branch. If you prefer a release branch, substitute it as appropriate.)
$ git merge technoweenie/master
Since Subversion scatters its .svn folders all over the place, we need to get rid of those. You can either do that manually or with a little find-fu.
$ find . -type d -name '.svn' -exec rm -rf {} \;
Excellent, that’s much better. Now it should be safe to check out the current state of affairs:
$ git status
Running this command will show you the currently untracked files. Those would be all files that existed locally before you started to create your own Git repository and which are non-existent in technoweenie’s repository.
Tracking local modifications
As I mentioned above, I didn’t have a boatload of local modifications. My changes were limited to bit of configuration, a few third party plugins (and the accompanying CSS/Javascript) and my local Mint installation. The additional files and directories that may show up are the cached HTML files that Mephisto sticks in public/.
To actually add your local modifications to your Git repository, simple add and commit them.
$ git add config/mongrel_cluster.yml
$ git commit -m 'Mongrel configuration'
If you’d prefer to rather ignore whatever else sits in your blog directory, add it to .gitignore
$ echo "public/*.html" >> .gitignore
$ echo "public/200*" >> .gitignore
$ echo "public/mint" >> .gitignore
$ git commit -m 'Ignore cache and mint' .gitignore
Cleaning up
I had a few files sitting in my directory that weren’t local modifications but seemed to have been removed from the official repository, too. Those weren’t caught by our merging of the Git branch since we started with zero history. To get rid of those, let’s take a look at git-clean.
$ git clean -n -d
Would remove app/views/admin/article_comments/
Would remove app/views/admin/articles/approve.rjs
Would remove app/views/admin/articles/comments.rhtml
Would remove app/views/admin/articles/destroy_comment.rjs
...
The -n argument prevents git clean from actually doing anything. If you’re confident it wouldn’t do anything harmful, go ahread and remove it. (You do have backups, right? Do you?)
At this point we’re down to regular upgrading business, so you might want to run the migrations and restart your Mongrel cluster. (Or whatever floats your deployment boat.)
$ rake db:migrate RAILS_ENV=production
$ mongrel_rails cluster::restart
Into the future
Now, whenever Mr. Weenie adds an exciting new feature to Mephisto you can grab that via:
$ git fetch technoweenie
$ git merge technoweenie/master
Or if you’d rather prefer to pick a specific commit:
$ git cherry-pick <SHA1>
Further reading
Since this is not a Git guide per-se, I’ll end the article at this point. There is plenty of other content available online to bring you up to speed with Git.
Post deployment log to Basecamp April 5th
I guess many of you have been reading the recent Signal vs. Noise blog post titled Using Basecamp to automatically keep track of product releases. I found it rather inspiring so I started to work on something similar for my own projects.
Out of that effort comes a super simple Capistrano plugin that grabs the first line from each commit (the subject in Git lingo) that happened between the last deploy and the current one and posts it as a new message to a pre-defined project (and category) on your Basecamp account using the Basecamp API.
Installation
$ cd <yourapp>/vendor/plugins
$ git clone git@github.com:scoop/basecamp_notify.git
It automatically hooks itself into your deployment process after deploy:symlink has run. Here’s a direct link to the GitHub repository.
If you don’t have git, you can download a tarball from GitHub, but read the caveat in the next section.
Configuration
The download ships with an example YAML configuration that needs to go into <yourapp>/config/basecamp.yml. It takes your Basecamp URL, username, and password as well as the numeric IDs for the project and category to post to, respectively.
Caveat: Since I wanted a fairly concise output in my posted messages (resembling what 37signals has in their example), I used a special command-line argument formatting thingamagick that only Git understands, so the plugin could be considered Git-only for now. Feel free to send in a patch that does the same for subversion.

Questions?
Email me at patrick@limited-overload.de if you have questions. Hope it’s useful for some of you.
UPDATE 04/11: basecamp_notify now has support for Subversion repositories. Thanks pyrat.
