Read about:

Archive for the ‘Programming’ Category

Autotest for Mac OS X – Now with less suck!

(Programming)

The autotest-fsevent and autotest-growl gems bring considerable improvements to ZenTest’s autotest for Mac OS X users.

autotest-fsevent teaches autotest a new trick: using FSEvent (provided in Mac OS X 10.5.x) instead of ordinary filesystem polling.  This means less CPU usage because FSEvent broadcasts filesystem changes, making active and periodic polling unnecessary.

autotest-growl enhances the Growl support that autotest comes with by adding support for Growling results for tests (using Test::Unit), specs (using RSpec), and features (using Cucumber) and adding pretty Ruby logos to the notifications.

If you use Mac OS X and autotest, I highly recommend that you try these gems out today:

sudo gem install autotest-fsevent
sudo gem install autotest-growl

One caveat: if you’re using ZenTest 4.0.0 or older, you need to do a bit of trickery to get autotest-growl to work properly.  These versions of ZenTest come with their own autotest Growl plugin, so you need to make sure you’re requiring the Growl support from autotest-growl instead of ZenTest’s own. Here’s what I ended up writing in my ~/.autotest file:

require '/Library/Ruby/Gems/1.8/gems/autotest-growl-0.1.0/lib/autotest/growl.rb'

From Git to SVN

(Programming)

There are many blog posts that talk about how to import a Subversion repository into Git but there isn’t much out there on how to work the opposite way.  After a bit of trial and error, I managed to figure out how to bring a Git repository into SVN and continue “pushing” updates from Git to SVN.

This might raise some questions for fervent Git fans: Why would anyone want to do this? Why not just keep everything in Git?

Here’s a personal anecdote: I developed a plugin for WordPress called GitPress. My initial development was done on GitHub, but in order for my plugin to be available via the WordPress Plugins Directory, I needed to bring everything from GitHub into WordPress’ SVN repository.  Here’s how I did it:

First, we create the initial SVN remote.  By using the standard layout (--stdlayout) and specifying the “gitpress/” prefix, I can easily get tracking branches for SVN branches, tags, and trunk.

git svn init --stdlayout --prefix=gitpress/ --username=enricob http://svn.wp-plugins.org/gitpress

Now, I fetch everything from the SVN remote that I’ve created and see if the remote branches are there:

git svn fetch

Now, when I list my remote branches in Git, I see gitpress/trunk, gitpress/tags, and gitpress/branches.  I create a local tracking branch for gitpress/trunk, which is where I’ll be pushing my changes:

git checkout -b svn-trunk gitpress/trunk

Now that I’m in my new tracking branch, I bring in the changes from my Git repository’s master branch:

git merge -s subtree master

Finally, I can commit my changes to SVN in one squashed commit:

git svn dcommit

I’ve also found that using git svn rebase causes separate commits to be made instead of getting a squashed commit, but the cases I’ve run into are pretty simple so far.

So that’s how I brought my GitHub project into an SVN repository. Hopefully this will help somebody else who might run into the same situation.