will do David - thanks for the link - great. So I'm not alone on this one after all :)
Greg On 3/9/07, Jamis Buck <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
