Sounds good. Give it a try! - Jamis
On Mar 7, 2007, at 11:28 PM, Greg Hauptmann wrote: > Hi Jamis, > > How about just (for the moment from the point of view of decreasing > turn-around time for "cap deploy" to work) > freeze rails in Dev per normal > mark the vendor/rails area of the app source as "not for SVN > versioning" ( i.e. don't check it in) > manually copy this "vendor/rails" area to a production server "/ > gregsarea/rails" (I think one may have to perform an svn export > here to obtain the "vendor/rails" directories without any SVN > artefacts ?? > add a separate step in the "cap deploy" process that, after > creating the new version area and checking out the application code > from SVN to this area, THEN copying the rails code in (like a copy > "/gregsarea/rails/*" to "current/vendor/" > How does this sound? > > Cheers > Greg > > > On 3/8/07, Jamis Buck <[EMAIL PROTECTED]> wrote: > Depends on what you mean by "best". svn:externals is certainly the > _easiest_ way, since it's one line of configuration and everything > "just works". > > If you want really really really fast, streamlined deploys, I've got > some ideas that I'm still cooking, but nothing that you can drop into > Capistrano and have work--it'd require a fair number of custom tasks > at this point. > > Currently, if you want to use the default Capistrano deployment tasks > with a minimum of fuss, you'll be best off just checking Rails into > your own repo under vendor/rails, or using svn:externals. Anything > else will require some custom-task-finagling. (Or finding a third- > party Capistrano extension that does what you want it to--there are a > few of them out there.) > > - Jamis > > On Mar 7, 2007, at 7:22 PM, Greg Hauptmann wrote: > > > Hi guys, > > > > Can anyone clarify/confirm the best way of manually copying rails > > into my application's vendor area in production, so not as to have > > it in SVN and avoid the overhead of the transfers when using > > Capistrano. > > > > Q1 - Is it as simple in unix as just creating a "rails" symlink > > under the "app/vendor" area that points to where I have copied the > > Rails code to? > > > > Q2 - Re the rails code to copy, can I assume I checkout rails code, > > and then do an svn export ( i.e. to get a copy of the codebase that > > doesn't include an SVN artifacts)? > > > > This concept seems easier than going for the svn:externals approach > > no? > > > > Tks > > 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. > > > > <cut> > > > > > > > > - Jamis > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
