Boy, am I glad to see a new Deploying Rails group. Over the last several months, I've been working on a Rails project on Windows XP. I've been deploying fine to Dreamhost with a Dreamhost SVN repository using Capistrano. Now I'm trying to convert to an OS X local environment. I used the excellent Hivelogic walkthrough to set up my OS X environment: http://hivelogic.com/narrative/articles/ruby-rails... Everything was humming along until I attempted to deploy some changes out to Dreamhost. Essentially, the error was "command not found: svn ..." Since my PATH was functioning fine in all other cases as I went through the walkthrough, I tried setting :svn to /usr/local/bin/ svn (with set :svn, "/usr/local/bin/svn"). Unfortunately this did nothing for me - same error. ~/.bash_login: export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin: $PATH" Typing "svn" in a bash terminal nets me "svn: command not found". Anyone have an idea what I'm missing? Full error output: * querying latest revision... /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27: command not found: svn log -q --limit 1 http://svn.bjhess.com/scrawlers/scrawlers /usr/lib/ruby/gems/1.8/gems/capistrano-1.3.1/lib/capistrano/scm/ subversion.rb:24:in `latest_revision': Could not determine latest revision (RuntimeError) from /usr/lib/ruby/gems/1.8/gems/capistrano-1.3.1/lib/ capistrano/configuration.rb:62:in `initialize' from /usr/lib/ruby/gems/1.8/gems/capistrano-1.3.1/lib/ capistrano/configuration.rb:62:in `call' from /usr/lib/ruby/gems/1.8/gems/capistrano-1.3.1/lib/ capistrano/configuration.rb:88:in `' from /usr/lib/ruby/gems/1.8/gems/capistrano-1.3.1/lib/ capistrano/configuration.rb:235:in `method_missing' from ./config/deploy.rb:43:in `instance_eval' from /usr/lib/ruby/gems/1.8/gems/capistrano-1.3.1/lib/ capistrano/configuration.rb:149:in `instance_eval' from /usr/lib/ruby/gems/1.8/gems/capistrano-1.3.1/lib/ capistrano/configuration.rb:149:in `load' from /usr/lib/ruby/gems/1.8/gems/capistrano-1.3.1/lib/ capistrano/configuration.rb:146:in `load' ... 7 levels... from /usr/lib/ruby/gems/1.8/gems/capistrano-1.3.1/lib/ capistrano/cli.rb:12:in `execute!' from /usr/lib/ruby/gems/1.8/gems/capistrano-1.3.1/bin/cap:11 from /usr/bin/cap:16:in `load' from /usr/bin/cap:16
on 2007-02-04 21:08
on 2007-02-04 21:57
Hello there. Macintosh OS X doesn't ship with Subversion. Have you installed it? Is there an svn command in any of these places? /usr/local/bin/mysql /usr/local/sbin/mysql /usr/local/mysql/bin/mysql (the last would be a weird place!) Can you use svn for other purposes? I'm assuming so, since it seems you're still developing... This is a bit strange, but I'm sure we can easily get to the bottom of this.
on 2007-02-04 22:00
You must have used his guide early yesterday. He added svn installation to the guide at some point yesterday Pull it back up and go through the svn steps!
on 2007-02-04 22:05
Thanks for the reply. SVN is in /usr/local/bin. If I type "/usr/local/bin/svn help" in the terminal, I do see the SVN help output. "svn help" gets me nothing but "command not found." I am using ZigVersion as a GUI tool to work with the repository on Dreamhost, and that works fine. This _seems_ like a PATH problem, but: a) I'd think setting :svn in the deploy.rb configuration file would overcome that. b) I have no trouble accessing any other apps installed to /usr/local/ bin at the command line. Commands like "ruby -v" and "rails -v" work just fine without needing to be called with a full path.
on 2007-02-04 22:59
Erik, I definitely went through those SVN steps. I must have hit the site after he updated it.
on 2007-02-05 05:36
Thanks to Erik for the chat which helped me solve the problem. In the end, I had to move the export statement from ~/.bash_login to ~/.bash_profile (~/.bashrc or ~/.profile may have worked as well). So I followed the Hivelogic instructions, but for some reason my PATH was not being updated when the export statement sat in ~/.bash_login. Erik is going to talk Hivelogic (Dan Benjamin, I assume) to see what his reasoning was for selecting ~/.bash_login as the location for that statement. More than likely my system is just goofy. :) Thanks again, Erik!
on 2007-02-05 17:59
after going back and forth with Dan Benjamin on this (Thanks Dan!) and RTFM'ing 10 times I finally understood this passage: When bash is invoked as an interactive login shell, or as a non-inter- active shell with the --login option, it first reads and executes com- mands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. Which means: If you have a .bash_profile, your .bash_login (and .profile) are ignored. Shown here: i-am-a-Mac:~ kastner$ cat .bash_login export ERIK="cool dude" i-am-a-Mac:~ kastner$ bash -l i-am-a-Mac:~ kastner$ echo $ERIK i-am-a-Mac:~ kastner$ mv .bash_profile .bash_old_profile i-am-a-Mac:~ kastner$ bash -l i-am-a-Mac:~ kastner$ echo $ERIK cool dude i-am-a-Mac:~ kastner$
on 2007-02-05 19:16
On Feb 5, 8:58 am, "Erik Kastner" <kast...@gmail.com> wrote: > after going back and forth with Dan Benjamin on this (Thanks Dan!) and > RTFM'ing 10 times I finally understood this passage: > When bash is invoked as an interactive login shell, or as a non-inter- > active shell with the --login option, it first reads and executes com- > mands from the file /etc/profile, if that file exists. After reading > that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, > in that order, and reads and executes commands from the first one that > exists and is readable. > > Which means: > If you have a .bash_profile, your .bash_login (and .profile) are ignored. This is fantastic! I've been carrying around a .bash_profile for over a decade and I've *always* wondered why .bash_login doesn't work for me when it works for everyone else! Thank you so much for this!