Thanks for taking time to respond Jamis, I'll stick with the standard commit/cap deploy approach (a bit heavy handed) to get the site working, but then follow up when I can with some of the suggestions you gave.
I'm kind of getting the feel that Capistrano is focused around production releases as opposed to more frequent developer updates to the server as part of continuing testing. For example I can only really test the Paypal integration by deploying to my host provider. Perhaps for these cycles I should just use a simple FTP client and upload changes to files as I make them to allow faster turn around times, for the integration testing phase. Cheers Greg On 2/18/07, Jamis Buck <[EMAIL PROTECTED]> wrote: > > > On Feb 17, 2007, at 1:35 AM, Greg Hauptmann wrote: > > > Hi, > > > > I had some questions on capistrano now that I've had to "freeze > > rails" for the first time as Dreamhost isn't on the latest version > > yet. So I'm assuming I will freeze rails into my application, add > > the new vendor/rails directory to my subversion repository ( i.e. > > will commit all the rails files as part of my application), then > > run "cap deploy" to upload the whole application including the > > local rails files to my server. > > > > Q1 - Is this the normal process here? ( i.e. committing the rails > > files) > > More or less. Some folks use svn:externals to basically link to a > revision of rails directly, rather than checking the entire rails > codebase into their own application, but the check-in approach is > being used by people, too. There are other methods in use as well, > though they require more setup and maintenance; one such approach is > where you would check-out (or copy) rails to your app's "shared" > directory on each target server, and then symlink to it on each deploy. > > > Q2 - Does Capistrano load only differences using SVN, otherwise > > each cap deploy would be a big upload? > > No, cap (by default) does an svn checkout operation on deploy, which > means it pulls the entire code-base from your repository, every time. > Some have implemented alternative strategies for cap, though, that do > incremental deploys; you can try searching this list (or the web in > general) for some tips for doing that. > > - Jamis > > > > > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
