Robby on Rails: Tag subversion

Interviewed by Hanselminutes

Robby Russell — Fri, 11 Apr 2008 08:31:00 -0500

Earlier this week, Scott Hanselman from Hanselminutes came down to the Planet Argon studio to interview Andy, Gary, and myself about adoption of Git.

The podcast interview is available online now.

Thanks for stopping by Scott!

update: I’d recommend that you also check out another episode of Hanselminutes when he sat down to speak with David Heinemeier Hansson and Martin Fowler.

git-svn is a gateway drug

Robby Russell — Thu, 10 Apr 2008 22:28:00 -0500

As we’re migrating away from Subversion to Git, I’m having to learn a lot about git-svn. Andy has posted a few articles on this topic, but I wanted to share a quick tip that I find myself forgetting.

Working with Subversion branches

While you’re hopefully already familiar with how great local branches are with Git, you might not know that you can connect local branches to remote branches in your Subversion repository. This allows those of us who are using Git locally to work against Subversion branches.

I’m going to assume the following:

Your team is using Subversion
Your team already has a branch that you’re working in
Your team is following Subversion directory conventions (branches/, tags/, and trunk/)
You have Git installed (with SVN extensions)

Checkout the Subversion project with Git

Please visit Andy’s tutorial, Git SVN Workflow, for a more detailed explanation of the following commands.

First, we’ll initialize your new local Git repository with git-svn.


  git svn init -s http://svn.yourdomain.com/repos/project_name

Now, you’ll change directories to your new Git repository.


  cd project_name

Let’s fetch all previous revisions into your local repository¹.


  git svn fetch

Great, once this is done… you’re master (local) branch is linked to trunk/.

Mapping a local repository to a remote branch

Assuming that your team is working in a Subversion branch on the current iteration of work. Our team has a naming convention for branches for each iteration. For example, if we’re in Iteration 18, we’ll write this as ITER-018 everywhere (Basecamp, Lighthouse, Subversion, etc…). At the start of each iteration, we create a new branch with this naming convention.

For ITER-018, the Subversion branch would be located at:

http://svn.yourdomain.com/repos/project_name/branches/ITER-018

If you were to do a git branch -r, you should see ITER-018 show up in the list. Now, the one thing that wasn’t clear when I first read the git-svn documentation was that you can’t just checkout that branch with one command. In fact, this has tripped me up a few times.

First, you’ll need to checkout a new local branch. I’ve opted to come up with my own convention for local branches and in this case, I’ll name it iter_018.


  git co -b iter_018

So, now I’m in the iter_018 branch, which is local. I’m currently still mapped to trunk/, which isn’t what we want. However, all we need to do is reset where Git is currently pointed to. We can run git reset to point this to the ITER-018 branch.


  git reset --hard ITER-018

That’s it! Now, the local iter_018 branch will point to branches/ITER-018 in your Subversion repository. This will allow you to work with your existing repository branch and still reap the benefits of local Git repositories.

What about master?

Good question. The git reset command that you ran will ONLY apply that that individual local branch. So, master is still pointing to trunk/. This will allow you to have several local branches that map to remote branches.

Next Steps…

If you’re working with Git already.. great!

If you’re working in an environment that using Subversion, git svn provides you the ability to start exploring Git without making your entire team switchover. Perhaps your a consultant and working for a client that uses Subversion… no problem!

We’re still using Subversion for past client projects and are considering GitHub, which just launched (to the public) today for future projects. A few of us are already using GitHub for open source projects.

Fun.. I just saw the following tweet pass by as I began to wrap up this post.

Uploaded with plasq’s Skitch!

Check out Rails on GitHub!

The Gateway Drug… Git reminds me of Cake

Questions?

I know that I glossed over a few things, so feel free to post questions and/or tips for others who are looking to dabble with Git.

¹ You’ll likely have problems if you don’t have a Git authors file specified in your git config.

I am forking Rails

Robby Russell — Wed, 02 Apr 2008 15:01:00 -0500

...well, creating a fork on GitHub. ;-)

Uploaded with plasq’s Skitch!

It appears that Rails is moving from Subversion to Git!

Courtenay posted this a little while ago.


git clone git://github.com/rails/rails.git

Check it out the Ruby on Rails project on GitHub.

Start working on your next patch with git…


git clone git://github.com/rails/rails.git
cd rails
git br -a
git br my_patch
git co my_patch

This is cool news. :-)

Learning Git without getting your SVN feet wet

Robby Russell — Tue, 11 Mar 2008 01:59:00 -0500

Our team has been migrating towards using Git as our primary SCM. We have way too many Subversion-based projects and repositories to just do a clean switch over and not everybody on the team has had time to start playing with it. Baby-steps…

So, for those of us who want to use it day-to-day, we’re using git-svn.

Andy Delcambre has posted the first in a series of blog articles to help you pick up on using Git on Subversion-based projects. Check out his article, Git SVN workflow to get up to speed.

Also, if you’re on OSX and using Git… check out Justin Palmer’s new project, GitNub, which describes itself as, “a Gitk-like application written in RubyCocoa that looks like it belongs on a Mac.” This looks promising. :-)

Launch your own RubyURL

Robby Russell — Sat, 01 Mar 2008 18:31:00 -0600

A few weeks ago, I moved RubyURL from subversion to git. During that process, I decided to use my invite to GitHub and have decided to go ahead and open up the source code.

It’s currently a whopping 92 LOC with a 1:2.5 code to spec ratio. (I had a goal to keep is below 100 LOC)

RubyURL on GitHub: http://github.com/robbyrussell/rubyurl
Public Clone URL: git://github.com/robbyrussell/rubyurl.git

Feel free to grab it and help contribute. This has served almost 14 million redirects since August 2007 and is running on a Rails Boxcar.

To grab it with git.. run: git clone git://github.com/robbyrussell/rubyurl.git.

Feel free to submit tickets to the Rubyurl ticket system.

http://planetargon.lighthouseapp.com/projects/4059-rubyurl

Enjoy!

UPDATE Ryan McGeary was kind enough to be the first person to help track down a bug and submit patches. :-)

Installing Ruby on Rails and PostgreSQL on OS X, Second Edition

Robby Russell — Tue, 19 Jun 2007 13:54:00 -0500

It’s been just over a year since I posted the article, Install Ruby, Rails, and PostgreSQL on OSX and it still gets quite a bit of traffic. Unfortunately, there have been a few changes in the install process that have caught people.

Today, I am leaving my PowerBook G4. It’s being replaced with a MacBook because the logic board is on the fritz. So, guess what that means? I get to install Ruby, Ruby on Rails, PostgreSQL on OS X again! I figured that I would post a revised version of my previous article for those who may go through this same process in the near future.

WARNING: This post contains some outdated instructions. Please read Installing Ruby on Rails and PostgreSQL on OS X, Third Edition, which is focused on Installing Ruby on Rails on Leopard.

Step Zero: Install iTerm (optional)

You’ll spend a lot of time in your terminal as a Rails developer. I’m not a big fan of Terminal.app as it lacks tabbed windows¹ and you’ll often find me with around ten tabs open. I’ve been using iTerm for a few years and it’s definitely improved in the past year and doesn’t seem to crash nearly as often as it used to.

Download the latest iTerm release

Once installed, I always change the default color scheme as I prefer the white on black schema. The menus in iTerm are lacking some thoughtful interaction design, but I’ve figured out the right way to do it (after a long time of stumbling on it by accident). In iTerm, you’ll want to edit the Default bookmark, which you can access by going to Manage Bookmarks under the Bookmarks Menu.

Set the Display value to classic iTerm and you’re golden.

Now… let’s get to business…

Step 1: Install Xcode Tools

Without installing Xcode tools from Apple, we’re not going to get very far. First, you’ll need to grab a copy of Xcode, which you can download on Apple’s Developer Connection site. It’s almost a 1GB download, so you’ll want to start your download and use your multi-tasking skills and grab a Viso, read some blog posts.

Download Xcode (dmg)

I’m going to make the assumption here that you know how to install a dmg on osx. Once this is installed, you can move on to the next step!

Step 2: All Your MacPorts are Belong to Us

MacPorts (formerly known as DarwinPorts) is a package management system for OS X. This is what we’ll use to install most of the necessary programs to develop and run your Ruby on Rails applications. If you’re from the Linux or BSD world, you are likely familiar with similar tools… such as: apt-get, port, and yum.

You’ll want to download MacPorts and install the dmg file.

Now that this is installed, we should test it.

With a new terminal, run the following:


$ port version
Version: 1.442

Success! Let’s get going…

Step 3: Installing the Ruby on Rails development stack

We’re going to go through a series of small steps, which may take some time depending on how fast your internet connection and computer is.

Install Ruby and RubyGems

In order to install Ruby, we’re going to use MacPorts with the port command, which is now available for installing various packages on our OS X machines.

$ sudo port install ruby rb-rubygems

It’ll probably take a while to download and install Ruby and all of it’s known dependencies. In the meantime, check out some funny code. KTHXBYE!

Still waiting for it to install, perhaps you could do something like… begin writing a comment on this post, writing your own blog post, watch a funny video, or recommend me. I walked to Backspace with Gary to get an Americano… and it’s still not done. :-p

(minutes/hours/weeks later)

Okay… I trust that it finished installing Ruby and RubyGems without any hiccups. Let’s test them from our terminal to make sure.

Let’s check the version…


$ ruby -v
ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.9.1]

Now, let’s make sure that Ruby is working properly…

$ irb
irb(main):001:0> x = 1     
=> 1
irb(main):002:0> puts "wee!!!" if x == 1
wee!!!

Great, we’re on a roll. Let’s get the rest of the stack installed.

Install Ruby on Rails

We’re going to install Ruby on Rails with the gem command that installing RubyGems provided.


$ sudo gem install -y rails

This command should produce an output similar to the following.


Successfully installed rails-1.2.3
Successfully installed rake-0.7.3
Successfully installed activesupport-1.4.2
Successfully installed activerecord-1.15.3
Successfully installed actionpack-1.13.3
Successfully installed actionmailer-1.3.3
Successfully installed actionwebservice-1.2.3
Installing ri documentation for rake-0.7.3...
Installing ri documentation for activesupport-1.4.2...
Installing ri documentation for activerecord-1.15.3...
Installing ri documentation for actionpack-1.13.3...
Installing ri documentation for actionmailer-1.3.3...
Installing ri documentation for actionwebservice-1.2.3...
Installing RDoc documentation for rake-0.7.3...
Installing RDoc documentation for activesupport-1.4.2...
Installing RDoc documentation for activerecord-1.15.3...
Installing RDoc documentation for actionpack-1.13.3...
Installing RDoc documentation for actionmailer-1.3.3...
Installing RDoc documentation for actionwebservice-1.2.3...

Install Rails-friendly gems

Mongrel

If you’re developing with Rails, it’s highly recommended that you use install and use Mongrel for your development and production environments. The following command will install the mongrel and mongrel_cluster gems (including their dependencies).

$ sudo gem install -y mongrel mongrel_cluster

* Note: Be sure to select the proper platform for mongrel. (hint: OS X is NOT mswin32)

My terminal output:


$ sudo gem install -y mongrel mongrel_cluster
Password:
Bulk updating Gem source index for: http://gems.rubyforge.org
Select which gem to install for your platform (i686-darwin8.9.1)
 1. mongrel 1.0.1 (mswin32)
 2. mongrel 1.0.1 (ruby)
 3. mongrel 1.0 (mswin32)
 4. mongrel 1.0 (ruby)
 5. Skip this gem
 6. Cancel installation
> 2
Select which gem to install for your platform (i686-darwin8.9.1)
 1. fastthread 1.0 (ruby)
 2. fastthread 1.0 (mswin32)
 3. fastthread 0.6.4.1 (mswin32)
 4. fastthread 0.6.4.1 (ruby)
 5. Skip this gem
 6. Cancel installation
> 1
Building native extensions.  This could take a while...
Building native extensions.  This could take a while...
Successfully installed mongrel-1.0.1
Successfully installed daemons-1.0.6
Successfully installed fastthread-1.0
Successfully installed gem_plugin-0.2.2
Successfully installed cgi_multipart_eof_fix-2.1
Installing ri documentation for mongrel-1.0.1...
Installing ri documentation for daemons-1.0.6...
Installing ri documentation for gem_plugin-0.2.2...
Installing ri documentation for cgi_multipart_eof_fix-2.1...
Installing RDoc documentation for mongrel-1.0.1...
Installing RDoc documentation for daemons-1.0.6...
Installing RDoc documentation for gem_plugin-0.2.2...
Installing RDoc documentation for cgi_multipart_eof_fix-2.1...
Successfully installed mongrel_cluster-0.2.1

Step 4: Installing the World’s Most Advanced Database Server… PostgreSQL!

At PLANET ARGON, we develop our applications on top of PostgreSQL. I’ve long been advocating the adoption of this awesome open source database in the Rails community. Just over a year ago, Jeremy Voorhis (PLANET ARGON alumnus) and I were interviewed on the Ruby on Rails podcast and had the opportunity to discuss our preference of PostgreSQL over the alternatives (mysql, sqlite, firebird, etc.).

We’re going to install PostgreSQL 8.2 from MacPorts by running the following command.

$ sudo port install postgresql82 postgresql82-server

While this is installing, you might take a moment to check out some space shuttles.

Setting up PostgreSQL

You may have noticed the output of the previous port installation of PostgreSQL 8.2, suggested that you do the following. Let’s do that now…


$ sudo mkdir -p /opt/local/var/db/postgresql82/defaultdb
$ sudo chown postgres:postgres /opt/local/var/db/postgresql82/defaultdb
$ sudo su postgres -c '/opt/local/lib/postgresql82/bin/initdb -D /opt/local/var/db/postgresql82/defaultdb'

Have PostgreSQL start automatically on system start-ups

Unless you’re concerned about extra applications running in the background, I’d encourage you to add PostgreSQL to launchd, which will start it automatically after system reboots.

$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql82-server.plist

Adding PostgreSQL commands to your $PATH

For some reason, MacPorts doesn’t add the PostgreSQL programs to the default bash PATH, which means that you can’t run psql, pg_dump, or createdb/dropdb without specifying the full path to where they were installed. What we’ll do is add them to our default terminal profile.

sudo vi /etc/profile

(you can use mate, emacs, joe or any other preferred editor to do this)

This file gets loaded every time a new terminal session is started.

Let’s add /opt/local/lib/postgresql82/bin to the end of the value for PATH.


PATH="/bin:/sbin:/usr/bin:/usr/sbin:/opt/local/lib/postgresql82/bin"

Save the file and then open a new terminal. To test this, you should get the following output when you run which psql.


$ which psql
/opt/local/lib/postgresql82/bin/psql

Creating a new PostgreSQL user

When I’m working on Rails applications in my development environment, I really don’t want to have to specify a username and password in every config/database.yml file for each of our ongoing client projects. When PostgreSQL was installed, it created a superuser named postgres, which is great, but I’d like one that matches my system username, so that I’m not prompted at all for a username or password to connect to PostgreSQL.

To do this, we’ll use the createuser command, which comes with PostgreSQL. As you can see, I’m creating a new user with superuser privileges (and will hopefully be the last time I have to do a -U postgres).


$ createuser --superuser robbyrussell -U postgres
CREATE ROLE

Let’s take a quick moment to test this out.


# create a new database
$ createdb my_test_db
CREATE DATABASE

# drop the database
$ dropdb my_test_db
DROP DATABASE

Great, everything looks good here.

We now have a running installation of PostgreSQL with a new user account. All we need to do now is install the appropriate RubyGem to allow our Ruby applications to connect to it.

Installing the Ruby Postgres gem

UPDATE: Hydro posted a commented, which lead me to the ruby-postgres gem.

You can install ruby-postgres gem by running the following command.


$ sudo gem install -y ruby-postgres

Let’s take a moment to test that this installed properly.


$ irb
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'postgres'
=> true

If this returns true, than we should be good to go. We’ve now built a professional development environment for working with Ruby on Rails. Doesn’t that feel great?

Test your install

You can look back at my older post to walk through the process of testing out your setup with a new Rails application.

Closing thoughts

I hope that this post has been useful for you. It took me a few hours to walk through this process and it’s how all of our designers and developers at PLANET ARGON installs and configures their development environment.

We also install the following programs on new machines.

TextMate
Subversion: sudo port install subversion
RSpec: sudo gem install -y rspec
...amongst other gems that are needed on specific projects

Until next time… have fun!

¹ Rumor: Mac OS X Leopard will give Terminal.app tabs! (see screenshot)

RSpec Bundle for TextMate

Robby Russell — Mon, 12 Feb 2007 07:58:00 -0600

Just a quick follow up to my post last night, Sharing Custom TextMate Bundles with Subversion. It appears that I missed the RSpec bundle for TextMate, which is listed on the RSpec webpage.

Install the RSpec Bundle

Installation is quite simple, just change directories to your TextMate bundle directory.


    $ cd ~/Library/Application\ Support/TextMate/Bundles/

Check out the RSpec bundle from the subversion repository.


    $ svn co svn://rubyforge.org/var/svn/rspec/trunk/RSpec.tmbundle
    # lots of files...
    A    RSpec.tmbundle/Support/spec/fixtures/example_failing_spec.rb
    A    RSpec.tmbundle/Support/spec/fixtures/example_passing_spec.rb
    A    RSpec.tmbundle/Support/spec/spec_mate_spec.rb
    Checked out revision 1489.

Now, just reload your bundles in TextMate and you’re good to go!

Bundles > Bundle Editor > Reload Bundles

I’d like to thank Aslak Hellesøy for pointing me to this and for also providing me with the correct subversion URL, which is currently outdated on the RSpec page until the next release.

Sharing Custom TextMate Bundles with Subversion

Robby Russell — Sun, 11 Feb 2007 23:35:00 -0600

Early last year, I began to start creating a bunch of snippets and such for TextMate, all of which were lost several months ago due to Hurricane iSight. I recently decided to start building some again, especially some that sped up my RSpec writing. After creating a few, I wondered, “would anybody else on my team want to help me write some?” So, I thought that it was time to figure out how to share my bundle with others and allow them to add stuff to it… which seems like a good job for Ms. Subversion.

I couldn’t find a quick walk-through online and found myself in the #textmate IRC channel getting proper instructions. (thank you Allan!)

Create Your Bundle

In TextMate, you can open up the Bundle Editor and create a new bundle. Let’s call our custom bundle, RSpec. Go ahead and begin adding some snippets, commands, etc to your new custom bundle. Once you have something in your Bundle, you’ll want to reload your bundles, by going to Bundles > Bundle Editor > Reload Bundles. This will write your new bundle to disk to ~/Library/Application\ Support/TextMate/Bundles/.


    $ ls -al ~/Library/Application\ Support/TextMate/Bundles/
    total 0
    drwxr-xr-x   5 robbyrus  robbyrus  170 Feb 11 21:10 .
    drwxr-xr-x   4 robbyrus  robbyrus  136 Feb 11 20:11 ..
    drwxr-xr-x   5 robbyrus  robbyrus  170 Jan 12 16:58 PLANET ARGON.tmbundle
    drwxr-xr-x   3 robbyrus  robbyrus  102 Feb 11 21:10 RSpec.tmbundle
    drwxr-xr-x   4 robbyrus  robbyrus  136 Oct 21 13:38 Robby Russell???s Bundle.tmbundle

Importing your Bundle into Subversion

You’ll want to first import your new bundle into Subversion.


    $ cd ~/Library/Application\ Support/TextMate/Bundles/
    $ svn import RSpec.tmbundle/ -m "Initial import of RSpec (test) bundle" http://{respository_url}/{repository_name}/RSpec.tmbundle/
    Adding         RSpec.tmbundle/info.plist
    Adding         RSpec.tmbundle/Snippets
    Adding         RSpec.tmbundle/Snippets/new specification.tmSnippet

Great, now it’s in Subversion. Now, you’ll want to check it back out so that TextMate is running off of the version from Subversion.

The simplest way to do this is to delete your local copy and checkout the latest from Subversion.


    $ rm -rf RSpec.tmbundle/; svn co http://{respository_url}/{repository_name}/RSpec.tmbundle/
    A    RSpec.tmbundle/Snippets
    A    RSpec.tmbundle/Snippets/new specification.tmSnippet
    A    RSpec.tmbundle/info.plist
    Checked out revision 5.

All that you need to do now, is relaod your bundles again. Now that you know where the bundle files are stored, you can commit any changes as they are made.

Committing Bundle Changes

When you make changes to your TextMate bundle, you can do the following to commit your updates to the Subversion repository.

See Your Pending Changes

You can change directories to your custom bundle and run svn status.


    $ cd ~/Library/Application\ Support/TextMate/Bundles/RSpec.tmbundle/
    $ svn status
    ?      Snippets/new context.tmSnippet

You’ll see that the new snippet that I created needs to be added to Subversion.


    $ svn add Snippets/new\ context.tmSnippet 
    A         Snippets/new context.tmSnippet

Now, let’s commit it to the repository.


$ svn ci -m "Adding new context snippet" 
Adding         Snippets/new context.tmSnippet
Transmitting file data .
Committed revision 6.

At this point, all Subversion tips and tricks apply… so… it’s time to leave it to you to figure out the rest. :-)

TIP: Always reload your bundles before and after running svn update or svn commit

...and there you have it! You and your friends can (with a little work) share and develop your own custom bundles for TextMate. I’m hoping to get my teammates at PLANET ARGON to help me build a bunch for RSpec, which I’ll try to release into the wild soon. If anybody is already working on RSpec snippets and other TextMate hacks, please let me know.

UPDATE

Aslak kindly commented on this post and has pointed me to bundle available in the RSpec subversion repository, which I blogged about.) :-)

Happy hacking!

Every Second Counts with a Piston in your Trunk

Robby Russell — Tue, 16 Jan 2007 01:15:00 -0600

Recently, I wrote about using RSpec and autotest (...which I think should be called autospec) together to help boost productivity while working on Rails projects. It seems that a few members of the PLANET ARGON team have picked up on using it, which I’m happy to hear about. :-)

It’s not the only thing that I’m happy about though.

I recently came across another gem. Several of my comrades in #caboose are using piston to manage external plugins for Ruby on Rails. Wait! Isn’t this what Subversion externals is meant for? Well, yes… but externals also eat away at productivity. For example, each day, we may have anywhere from 4-6 designers and developers working on one client project. When we’re in crunch mode, this could account for quite a few subversion commits throughout the day. We all know that we should run svn up on a regular basis to make sure that we’re keeping things in sync… especially when designers and developers are working really closely and fine tuning something specific in the application. Well, the one downside to this process is that each svn up not only checks our repository, but it also checks external repositories.

“But wait! Can’t you just ignore externals on an update?”

Of course, but who wants to type out --ignore-externals each time they run an update? ...or perhaps you could make an alias for this in your shell. In any event, everyone on the team is then left to be responsible for doing this… and an extra 30-60 seconds (if not longer) per svn update times x number of people on project… well… time wasted if you’re closely watching the svn updates. Also, TextMate doesn’t have an option currently (that I could find) to ignore externals, so for those who manage subversion through it… they’re waiting on externals within their primary workspace.

Another issue with svn externals is that when a repository goes down, it really starts to slow stuff down your updates. This is always fun when you go to deploy your application with Capistrano and realize that you can’t finish the update because it can’t connect it to http://svn.lazyatom.com/public/plugins/acts_as_hasselhoff/ to make sure that your application has the latest version of the best plugins available for Rails.

Then there is the whole issue of wanting to make changes to the plugin that you’re including as an external. How does that fit into the whole mix?

There is Hope!

Piston encourages you to keep your external plugins in your local repository. Don’t worry, it remembers where it retrieved the code from so that you can update from the external repository at any time.

Installing Piston

Again, this is really simple like most gems.


    $ sudo gem install -y piston
    Password:
    ...
    Successfully installed piston-1.2.1

Great, that’s all that you have to do to get started with Piston. Now, let’s get on with the show.

If you don’t have any existing Subversion externals, feel free to skip this section.

Converting existing externals

Okay, so let’s say that you’re working on a Ruby on Rails project and are relying on several external repsitories. For example, a project that I’m working on… currently looks like this.


    $ svn proplist --verbose vendor/plugins/               
    Properties on 'vendor/plugins': 
      svn:externals : 
    authorization                 http://svn.writertopia.com/svn/plugins/authorization
    svn_tools                     http://svn.planetargon.org/rails/plugins/svn_tools
    simply_helpful                http://dev.rubyonrails.com/svn/rails/plugins/simply_helpful
    exception_notification        http://dev.rubyonrails.com/svn/rails/plugins/exception_notification
    asset_field                   http://svn.planetargon.org/rails/plugins/asset_field
    rspec_on_rails                svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5/rspec_on_rails/vendor/plugins/rspec_on_rails
    rspec_autotest                http://svn.caldersphere.net/svn/main/plugins/rspec_autotest

Piston is smart enough to know how to convert these Subversion externals into Piston-friendly plugins. This can be done by passing the piston command the convert option from within your Rails application directory.

Go ahead and run the following.


    $ piston convert
    Importing 'http://dev.rubyonrails.org/svn/rails/tags/rel_1-2-0_RC1' to vendor/rails (-r 5619)
    Exported r5619 from 'http://dev.rubyonrails.org/svn/rails/tags/rel_1-2-0_RC1' to 'vendor/rails'

    Importing 'http://svn.writertopia.com/svn/plugins/authorization' to vendor/plugins/authorization (-r 83)
    Exported r83 from 'http://svn.writertopia.com/svn/plugins/authorization' to 'vendor/plugins/authorization'

    Importing 'http://svn.planetargon.org/rails/plugins/svn_tools' to vendor/plugins/svn_tools (-r 119)
    Exported r119 from 'http://svn.planetargon.org/rails/plugins/svn_tools' to 'vendor/plugins/svn_tools'

    Importing 'http://dev.rubyonrails.com/svn/rails/plugins/simply_helpful' to vendor/plugins/simply_helpful (-r 5700)
    Exported r5700 from 'http://dev.rubyonrails.com/svn/rails/plugins/simply_helpful' to 'vendor/plugins/simply_helpful'

    Importing 'http://dev.rubyonrails.com/svn/rails/plugins/exception_notification' to vendor/plugins/exception_notification (-r 3900)
    Exported r3900 from 'http://dev.rubyonrails.com/svn/rails/plugins/exception_notification' to 'vendor/plugins/exception_notification'

    Importing 'http://svn.planetargon.org/rails/plugins/asset_field' to vendor/plugins/asset_field (-r 50)
    Exported r50 from 'http://svn.planetargon.org/rails/plugins/asset_field' to 'vendor/plugins/asset_field'

    Importing 'svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5/rspec_on_rails/vendor/plugins/rspec_on_rails' to vendor/plugins/rspec_on_rails (-r 1330)
    Exported r1330 from 'svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5/rspec_on_rails/vendor/plugins/rspec_on_rails' to 'vendor/plugins/rspec_on_rails'

    Importing 'http://svn.caldersphere.net/svn/main/plugins/rspec_autotest' to vendor/plugins/rspec_autotest (-r 48)
    Exported r48 from 'http://svn.caldersphere.net/svn/main/plugins/rspec_autotest' to 'vendor/plugins/rspec_autotest'

    Done converting existing svn:externals to Piston

All we have to do now is checkin our changes to subversion and we’re golden.

svn ci -m "updating repository to use piston instead of those lame-o externals..."

If you find this interesting and want to learn more, be sure to check out this post on Ruby Inside for a detailed introduction to Piston.

update

the following morning I saw this come across our development team channel…

< argonbot> svn.commit( project_name, { :author => 'brian.ford', :rev => 83, :log => 'converted svn:externals to piston for product, cus I can.' }

:-)

The Zen of Auto Rspec

Robby Russell — Wed, 10 Jan 2007 11:08:00 -0600

Several months ago, I heard that people were using a program called autotest to have their tests continue to run as you made changes to your code base, which comes with ZenTest. It’s a really nice tool written by Ryan Davis and I hadn’t gotten a chance to play with it as of yet. Well, our team isn’t spending too much time in the test/ directory these days as we jumped ship near the end of last summer and found ourselves hanging out on the Isle of BDD. The locals are quite thoughtful about these sorts of things.

I just started working on a project that has been under development for several months and as I’m getting to learn the ins/outs of the system, I find myself having to rerun the specs, which can take quite a bit of time watching. Watching your specs or tests run sometimes is as productive as watching your code compile. Oddly enough, this is as close to compilation as we really get when working with Ruby on Rails… and it’s a productivity killer for me.

There Must Be a Better Way!

So, I did a quick google search and found an announcement for Rails that ran specs through ZenTest. This was exactly what I was searching for!

Some requirements

Please makes sure that you have the following gems installed in your development environment as they are dependencies to make this all work.

zentest
diff-lcs


$ sudo gem install zentest diff-lcs

note I’m going to assume that you have rspec and rspec for rails installed… if not… tsk. ;-)

Install RSpec autotest


$ script/plugin install http://svn.caldersphere.net/svn/main/plugins/rspec_autotest

If you’re using subversion, you might consider installing it as an external.


$ script/plugin install -x http://svn.caldersphere.net/svn/main/plugins/rspec_autotest

Running RSpec autotest

This is where it gets tricky. ;-)


$ rake spec:autotest

Now, you can keep a terminal window open and autotest will watch your application and detect when files change. When they change, it’ll attempt to rerun your specs (specifically those that changed). This helps save you the time of having to rerun all your specs throughout the development process and keep your spec:all sanity checks for when you’re about to commit code to your repository.

I’ll post another entry in the next few days to show you how you can use Growl with RSpec Autotest to keep you from having to look at your terminal all the time.

Until then… have fun!

the bizarre love triangle of rbot, subversion, and drb

Robby Russell — Thu, 15 Sep 2005 01:27:00 -0500

In our pursuit to get stuff ready for the PDX.rb hackfest this weekend, Ben Bleything and I decided that it would be a cool idea to get rbot to monitor the groups subversion repositories.

We asked around a few IRC channels and people had different ways of handling this. The easy route looked to be to parse a RSS feed from Trac. (boring!)

So, in an effort to make it interesting and allow for a little creativity with rbot-~~and potentially open the doors to other ideas~~-we opted to build 2 pieces. One would be a post-commit script that would run after a svn commit and the other would be a new plugin in rbot, which started an instance of DRb.

The basic idea…

rbot starts drb on start

svn commit calls drb client, sends notifcation

Yes! I managed to sneak DRb somewhere else that it probably didn’t need to be. It was actually a good way to figure out how to properly tame the crazy lion that is DRb. It’s so sexy, but I am so afraid that it will scratch me if I get too close. It scratched a little tonight, but then the kind folks in #ruby-lang gave me a band-aid and I was on my way. Guess what? I tamed the lion!

The sad part is that I got the thing to properly work about 25 seconds after Ben logged off of IRC and here I am a few horus later amusing myself with test svn commits and telling the whole world. That’s right… he’s sleeping… and dreaming about how the lion is still out to attack him and you all know that the lion is nicely tucked away.

Thread.new { 
  # the lion is here 
}

We couldn’t have the lion holding the rbot in a headlock the whole time.

So, the lion is nice and it is our new friend. We now have instant notifications of when our repositories get commits in #pdx.rb.

Once we get it to format everything nice and pretty (color-wise), we’ll make it available for all of you rbot and subversion folks.