Welcome Guest | Login

Struggling with subversion

I've got an existing rails app deployed on FastCGI that I'm trying to convert to subversion and Capistrano.  I'm new to both and really struggling.  I read the svn-book and followed the subversion single user tutorial wiki; now I'm more confused than ever.  Would anyone mind walking me through the process til I get to a known point where I can follow the capistrano tutorial again?

I followed the wiki verbatim.  As I understand it, I should now have a shell rails app in my svn repository.  But I cannot check out a copy of this app to my local machine.  When I enter this into my command line on my local machine:
svn co svn+ssh://<username>@<domainname>/home/<username>/svn/<appname>/trunk
I get a message saying "can't create tunnel: system can't find the file specified".  I've tried various svn commands from the server to try and look at the structure but can't find anything that works.

Also, I don't quite understand how to get my existing source code into this shell app?  Should I have imported my existing app at the server instead of the temp rails app per the tutorial?

Finally, once I get this done and I deploy on Capistrano, since this is a live app am I going to have to copy my database contents (data, not schema or migration) to a new database, or do I connect it to the existing database, or does Capistrano do some magic?

2008-11-10 07:45 PM

If all men were just, there would be no need of valor.
-- Agesilaus, 440 BC
Update: did manage to find the working copy of the shell app that I checked out to the server.  But not able to create tunnel to check out to local machine.

2008-11-10 09:05 PM

If all men were just, there would be no need of valor.
-- Agesilaus, 440 BC
You can check out the rails app from the server using TortoiseSVN as your SVN client, make sure that you have added the following entry(under the [TUNNELS] section) to the subversion config file.

----------
ssh = C:\\Program Files\\TortoiseSVN\\bin\\TortoisePlink.exe -ssh -l [username]
----------

See if that helps.

2008-11-10 09:07 PM

Yes, thank you, that helped.  I can now check out the shell app from my repository to my local machine.

What's next?  Do I copy my existing app files into the  working copy and then commit it back to the server?

2008-11-10 10:06 PM

If all men were just, there would be no need of valor.
-- Agesilaus, 440 BC
Hi Biged,

You can follow the given steps to commit the changes back to your svn repository.

svn add <file_name> # Only require if new file/ folder is adding to the svn repository

svn commit -m "message" # Commit the changes back to your repository.

Once the changes are committed to the svn repository you can execute the following commands to Cap deploy your rails app.

$ cap deploy:setup
$ cap deploy:cold

In future you can execute the following command to update the rails app on the current release with the new changes committed to the svn repository.

$ cap deploy

2008-11-10 10:41 PM

Now I'm running into the same problem with Capistrano.  I followed the wiki tutorial for Capistrano 2.x and set up the config.deploy and capfile as instructed.  When I run cap deploy I get the following error message:
*executing 'deploy:update'
** transaction: start
* executing 'deploy:update_code'
svn: Can't create tunnel: The system cannot find the file specified.
Given my previous problems, and the fact that the Capistrano default scm is subversion, I'm guessing that Capistrano is trying to connect to the server using my local subversion client and failing.  So I either have to configure Capistrano to work with TortoiseSVN or configure SVN to work properly.

I tried to configure Capistrano to work with Tortoise by changing the scm line in config.deploy to read
set :scm, :tortoisesvn
but that didn't work, got error message saying "could not find any SCM named tortoisesvn".  Also tried with "tortoise", with same result.

Can anyone help me set up my local subversion client so it connects to the server?

2008-11-11 11:57 AM

If all men were just, there would be no need of valor.
-- Agesilaus, 440 BC
Ok, I sorted that part of it out.  Had to set up ssh keys and configure my SVN client to use the key.  If anyone else wrestled with this, here is a quick tutorial on the basics.   http://agateau.wordpress.com/2007/07/03/windows-svnssh-and-the-subversion-command-line-client/

Probably should be in the wiki

Now cap deploy:update runs, but with a bunch of errors. I'll see if I can sort those out.

2008-11-11 03:02 PM

If all men were just, there would be no need of valor.
-- Agesilaus, 440 BC
Vinayan,

quick question on your advice above ...

Should that entry be made in the subversion config file on the server, the client, or both?

2008-11-11 06:55 PM

If all men were just, there would be no need of valor.
-- Agesilaus, 440 BC
The entry should be added in the subversion config file of your local machine.

2008-11-11 08:16 PM

Ok, that explains that.  I had it in the server config file.  It was throwing an error when I ran cap update:deploy.

Thanks, will fix that.

2008-11-11 08:52 PM

If all men were just, there would be no need of valor.
-- Agesilaus, 440 BC
Getting closer.  I think I'm almost there.  I can use subversion and TortoiseSVN to checkout and commit from local machine to server.  I can run cap deploy:cold without error messages, and it adds a revision to the directory structure under the home/username/apps directory.  

However, when I navigate to my app url, I'm getting the public file structure instead of the rails app.

2008-11-11 10:04 PM

If all men were just, there would be no need of valor.
-- Agesilaus, 440 BC
Please check your .htaccess file and dispachers to troubleshoot this issue. You can go through our tutorial link http://www.hostingrails.com/forums/wiki_thread/1 and make sure that all the settings are correct. If you are finding it difficult to troubleshoot it, please post a ticket to the support with your application path and URL we will help you out with the deployment.

2008-11-11 10:12 PM

HostingRails Support
Ok, got the app up and running, and cap deploy properly updates to new version.  You were right, had to go back and make sure my .htaccess, database.yml, and environment.rb files were configured properly.

Now I have to figure out how to ignore those files in the TortoiseSVN updates and commiets.  

Man, what a horrible PITA that was.  Thanks for the help.

2008-11-11 10:53 PM

If all men were just, there would be no need of valor.
-- Agesilaus, 440 BC
Anyone have any suggestions or strategies for which rails files to ignore in source control?

I've got one database.yml file with dev, test, and deployment DB settings.  It's under version control.  

I can't quite work out how to handle the two versions of environment.rb.  Right now I keep two files in my local working copy:  environment.local.rb and environment.online.rb.  When I'm developing, I rename environment.local.rb to environment.rb.  When I get ready to commit and deploy, I rename environment.rb back to environment.local.rb and rename environment.online.rb to environment.rb.  I commit, cap deploy, and then rename them back for further development.

Surely there is an easier way?  How can I set things up so I have an environment.rb in the server repository, a different environment.rb in my working copy, and SVN ignores the differences?

2008-11-12 04:42 PM

If all men were just, there would be no need of valor.
-- Agesilaus, 440 BC
Hi Biged,

You can either

1) Store the environment.rb file in the shared/config folder. Also environment.rb file can be sym linked to the current release and cap deploying by using the following line in the start and restart task of your Capfile.

run "ln -s #{deploy_to}/shared/config/database.yml #{current_path}/config/database.yml"

so you have to only keep the file environment.local.rb in your svn repository and after check out you can rename the file environment.local.rb to environment.rb temporarily and then revert back environment.rb to environment.local.rb while cap deploying.
              or
2) Just keep only one file environment.rb in your svn repository and then comment the line - ENV['RAILS_ENV'] ||= 'production' to set your rails app's version as development and un-comment the same while cap deploying.

2008-11-12 08:45 PM

Thanks.  Right now I'm developing on 2.1.2 and the server is running 2.1.0, so I've got several differences in the environment file related to gems.  That makes #2 a little more hassle, so I'll give #1 a shot.

Thinking about it, if I keep my online environment.rb in shared/config/ and symlink to it in capfile tasks, could I delete environment.rb from version control and set SVN to ignore it in my working file?  Then I could deploy without any renaming of files, right?

2008-11-13 05:25 PM

If all men were just, there would be no need of valor.
-- Agesilaus, 440 BC
In case anyone else finds this on search, I found a good solution:

1.  Save online versions of environment.rb and database.yml to the shared/config folder.
2.  Symlink them to the current release in the capfile as described 2 posts up.
3.  Delete environment.rb and database.yml from the working copy and commit so both are deleted from the repository.
4.  Add local versions of environment.rb and database.yml to the working copy and set subversion to ignore them.

That way cap deploying can be done without any renaming or editing of files.  

2008-11-19 12:37 PM

If all men were just, there would be no need of valor.
-- Agesilaus, 440 BC

Hello Guest! In order to post you must be an active client with us, please log in or sign up.