Subversion&Capistrano: symlink in wrong location??

I went through the whole Subdomain/MySql/Subversion/Capistrano song and dance two months ago and finally got my Ruby on Rails blog to work with all the above. Last night I started down that road again with a new app and can't find the light at the end of the subversion/capistrano tunnel.

Successful parts:
-Created 'rails newapp' locally on my powerbook (nothing in it yet, just bare bones)
-Created subdomain newapp.mydomain.com/current/public
-MySql: newapp_production sitting on db.mydomain.com with user/password info
-Subversion: svn.mydomain.com/newapp (created after the DNS for the subdomain was working)
-locally, run 'cap --apply-to .' in my newapp folder and get the config/deploy.rb and lib/tasks/capistrano.rake files added nicely.
-I edit all the files listed in the DH capistrano wiki entry and the DH subversion wiki entry. ie.public/.htaccess, public/dispatch.rb, config/environment.rb, config/deploy.rb (which I copy from my successsful blog's deploy.rb file, changing the names of the subdomains and app names.)

Non-successful part:
-in my local newapp folder, when I try to run 'svn add config/deploy.rb lib/tasks/capistrano.rake' I get an instant error of: " 'config' is not a working copy' ?!?!? I don't recall getting this error two months ago when I got my blog working. I've been following my notes from back then as well.

Continuing on with somewhat success:
-I run 'cap setup' locally in my newapp folder and it creates both the releases and shared folders in my newapp.mydomain.com folder on DH.
- I run 'cap deploy' locally and it seems to successfully create a new version at DH. In my DH's svn/newapp/db/revs folder, it shows a new file called '1', and in my DH's newapp.mydomain.com/releases folder there is a new version folder with a long-ass number.

HOWEVER, this is where it deviates from my previous success two months ago:
In my previous blog success, the blog.mydomain.com/current folder is inaccessable via ftp (is that the symlink?) and in this newapp, I can open the '/current' folder and inside is a long numbered folder that is inaccessable (same as the new folder in newapp.mydomain.com/releases folder). I can also open the newapp.mydomain.com/current/public folder and it is empty. In the other blog heirarchy, I cannot even get to the /current/public folder. What is going on? It seems like the symlink that is supposed to point the latest version folder inside releases to the '/current/public' folder is missing its mark by a level. When I go to my newapp subdomain in a browser, I get served up a semi-blank page with "Index of /" and links to "Name Last Modified Size Description" I cannot add /current or /current/public or /current/long-ass'd-version-number-folder in the URL as they all return 404 not found errors.

I have gone into my domain control panel and clicked 'edit' on my newapp subdomain and hit the 'edit this domain' button to hopefully restart it (what I did with the blog whenever I updated via capistrano/subversion).

If anyone can help, I would greatly appreciate it. I can post file & log contents if needed.
Thanks!!!!

Hey Jenz,

I found the answer at topfunky.com and then updated the capistrano wiki entry here at Dreamhost.
http://wiki.dreamhost.com/index.php/Capistrano

In the wiki, it used to say create a subdomain for your app like this, "app.mydomain.com/current/public" which is correct, (don't forget to add /current/public when creating the subdomain!), except that for capistrano to work a few steps later, you have to first manually delete the "/current/public & /current" folders (via ssh or ftp) that the dreamhost subdomain routine creates! The subdomain's path will still be pointing to the /current/public folder (which you just deleted).

Capistrano's 'cap deploy' command creates a symlink called '/current' off your app's subdomain. If there is already a folder called '/current' there, it screws it up (which is the original issue I was having). After you have deleted the "/current/public & /current" folders, rerun 'cap deploy' and see if it creates a /current folder (symlink) off your app's subdomain. You should not be able to view the contents of this folder via ssh or ftp since it's really a symlink. Go to your subdomain in your browser, do you see the rails welcome?

If it still isn't working, you may need to back track, removing the subversion repository (via dreamhost control panel) you just made for your app and manually remove the folders that 'cap setup' & 'cap deploy' make.

Removing capistrano created folders:
via ssh or ftp, below your app's subdomain remove the following:
current
releases
shared
revisions.log

Assuming your app is working locally:
1) Re-Create a subversion repository on the dreamhost server via their control panel
2) make sure your local app's environment.rb, public/dispatch.fcgi (#!/usr/bin/env ruby), public/.htaccess, deploy.rb files are edited.
3) run "cap --apply-to ." (without quotes) in your local app folder (you do have capistrano and subversion installed locally, right?). This creates the config/deploy.rb file, which you then have to edit per the wiki (part of my deploy.rb file listed below for you). If you had already done this step before, it will ask if you want to overwrite config/deploy.rb and lib/tasks/capistrano.rake. Your choice. If you overwrite deploy.rb, you have to redit it again per the wiki. capistrano.rake file is not edited prior to finishing the deployment, so you can overwrite that one no problem.
4) Copy (import) your current app from your local hard drive up to your subversion repository thusly (from within your local app folder):
svn import . http://svn.YOURDOMAIN.com/APPNAME -m ÒInitial ImportÓ This copies your local app up into subversion on the Dreamhost server. **If you don't have subversion installed locally, this may not work as I typed it. I've seen other's list the import line with an ssh element to it. I don't do it that way.
5) On your local machine, go up one folder level and rename your local app folder something like "originalAppName0", so if it was blog, make it blog0. This is so the next step doesn't wipe out your original local copy of your app if something goes wrong.
6) from that same folder (just above your renamed app folder) 'checkout' a copy of the subversion app you just uploaded. This will re-copy the same app folder back down to your hard drive, creating the originally named app folder, but now it will be under subversion control: (fixes the 'config is not a working copy' error)
svn co http://svn.YOURDOMAIN.com/APPNAME
7) Move into the newly created/downloaded app folder 'cd appname' and run: 'cap setup' which will create the releases folder and shared folder in your app's subdomain (on dreamhost).
8) From within your local app folder, run 'cap deploy' which finally looks at your dreamhost subversion repository, uploads your app as a new release version, creates the symlink to point to it and you're in business.

I think for all future updates, simply run from your local app folder:
svn commit -m Òdescription of changesÓ (may need to resemble svn import command above. ie.svn commit http://svn.yourdomain.com/appname -m "description of changes" because the first way may be a local only commital?)
cap deploy

I seem to recall reading that the reaper errors are permission errors. However, I found elsewhere a better way to restart your app on the server than reaper. Here is the bottom half of my deploy.rb file, which includes not only the apache restart (replacing the reaper way), but also a cooler deploy method in general. This deploy puts up the maintenance page (turning off the website), then uploads the code, updates the release version (symlink), then runs migrations on the server (VERY handy if you are creating your tables/fields via migrations), restarts apache, removes the maintenance page turning back on the website. The whole thing is via a transaction, so if any part fails, then it puts it all back the way it was prior to running 'cap deploy'.

Hope this works for you! I was able to create 5 other subdomains/subversionRepositories/Capistrano activated apps after finding that darn "delete /current/public folders" solution.
-=Randy

bottom half of my deploy.rb file:
==============================
#New deploy task!!
task :deploy, :roles => [:app, :db, :web] do
ENV['REASON'] = 'an application upgrade'
ENV['UNTIL'] = Time.now. (600).strftime("%H:%M %Z")
disable_web #put up the maintenance screen
transaction do
update_code #update the code
symlink #fix the symlink
migrate #run migrations
restart #restart the server
end
enable_web #remove the maintenance screen
end

#better apache restart
desc "Restart the web server."
task :restart, :role => :app do
sudo "apachectl graceful"
end
===========================

If this is all too confusing, send me an email randy_at_walkersystems_dot_net and I'll shoot you the step by step procedure I created for myself.
-=Randy

Edited by Owossoborn on 09/10/06 09:05 PM (server time).

Subversion&Capistrano: symlink in wrong location??