split up long method
Don't load commands in the client

Load commands in the server process instead. The client communicates
with the server to determine whether a command is available or not.

This means that the config/spring.rb can load commands which reside in
gems, without adversely affecting the startup time of the spring client.

Closes #79.
Fix race condition

This will (hopefully) fix the error seen on the CI.

After we send_io to the application process, it checks if
watcher.stale?. If so, it exits. So it could happen that the child is
alive, we send the io, then the child is stale, so it exits, so there is
no pid, so the client exits with no output. What should actually happen
is that we detect the exit and restart the child.
Unlock the mutex when we fork

Keeping it locked makes Ruby 2.0 crash when used in conjunction with
the listen watcher.
Revert "Unlock the mutex when we fork"

This reverts commit e67339aa13c457343175833a4e3fe7bf10a706da.

This was not actually the problem :(
Workaround Ruby 2 GC bug

It seems that Ruby 2 doesn't like it if the watcher.to_io ever gets
GC'd. It segfaults, see e.g.
https://travis-ci.org/jonleighton/spring/jobs/5174559.

I will try to produce a proper trace and report the bug, but in the mean
time this workaround seems to do the trick.
Disable autorun when running RSpec

Current versions of rspec-rails generate a spec_helper.rb file that
requires 'rspec/autorun'.  This allows individual specs to be run
using `ruby -Ispec path/to/spec`, but causes the spring `rspec`
command to run specs twice.  Disabling autorun before requiring
preloaded files (which will normally include spec_helper) prevents
this.
Use a timeout in assert_stale

This is generally faster than just sleeping for a fixed time period, and
hopefully avoids the timing issue (presumably) seen here:
https://travis-ci.org/jonleighton/spring/jobs/5424699
Ensure watcher works with paths which start with a dot
Merge pull request #98 from tomafro/disable-rspec-autorun

Disable autorun when running RSpec
Add a "spring start" command and use it internally to boot the server

This is kinda related to #89 in that it removes the ruby -e "..." line
from the backtrace, but it also seems cleaner in general.

Users don't really have any reason to run "spring start" manually since
it happens automatically when they try to run a command.
Stop using Mutex_m

It adds weird stuff to the backtrace, which is annoying, see #89.
Revert "Merge pull request #90 from rjackson/close_database_connections_before_forking"

This reverts commit d9869697bd18c8961f992c00882a6813a84fab27, reversing
changes made to c5913debf28a2657cc9d120cb5ccfc4e85c8ae66.

Explanation:

ActionDispatch::Reloader.prepare! ends up calling
ActiveRecord::Base.connection.clear_cache! which tries to get the
connection, and at least with a postgres database, raises an exception
because the connection has been closed.

We want to do the prepare! in the parent process so that autoloaded
constants are kept up to date. Otherwise the child process would have to
reload the files every time, even if they hadn't changes since the
previous run.

The easiest solution for now seems to be to revert this.
Status command list application in all terminals

Fixes #93
Merge pull request #105 from geigerzaehler/master

Status command lists applications across all terminals
Replace "spring [console|runner|generate]" with "spring rails"

Closes #76
Rename "spring test" to "spring testunit".

It's longer but it doesn't conflict with the bash builtin "test"
command.

The recommended way to run spring is via binstubs, so people can just
type "bin/testu<Tab>" anyway.

Also, rails 4 will have a "rails test" command that will be integrated
into spring too.

Fixes #64.
Add link to direnv
Add a changelog
bump version