I have noticed switchtower assumes you have your whole rails tree in subversion, even the files generated with the rails script. I only have the files I wrote my own or that override the ones generated by rails, and my deploy script just sits over rails generated tree. I am porting my deploy system to switchtower, is there a way to mmic this? Een further, I have my app splitted intro 3 different modules/svn dirs which get merged with my script using symlinks to the svn checkout in a unique webroot. Would be possible to mimic this also? Cheers Duncan
On Oct 5, 2005, at 7:38 AM, Duncan Mac-Vicar Prett wrote:> I have noticed switchtower assumes you have your whole rails tree in > subversion, even the files generated with the rails script. > > I only have the files I wrote my own or that override the ones > generated by > rails, and my deploy script just sits over rails generated tree. > > I am porting my deploy system to switchtower, is there a way to > mmic this? > > Een further, I have my app splitted intro 3 different modules/svn > dirs which > get merged with my script using symlinks to the svn checkout in a > unique > webroot. Would be possible to mimic this also?It is certainly possibly, but not with the default tasks. You''ll need to write your own SwitchTower tasks to handle your particular deployment scenario. As with the rest of rails, SwitchTower has some strong opinions that are enforced by the default tasks. Conforming to the expectations definitely makes life easier, but with some effort you can use SwitchTower to deploy most configurations. - Jamis
On Wednesday 05 October 2005 15:50, Jamis Buck wrote:> As with the rest of rails, SwitchTower has some strong opinions that > are enforced by the default tasks. Conforming to the expectations > definitely makes life easier, but with some effort you can use > SwitchTower to deploy most configurations.yeah, I noticed. Just for me it is to strange to see most people then would put generated files like the ones under script/ under svn... I am trying to make sense of it. Duncan
On 10/5/05, Duncan Mac-Vicar Prett <dmacvicar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Wednesday 05 October 2005 15:50, Jamis Buck wrote: > > As with the rest of rails, SwitchTower has some strong opinions that > > are enforced by the default tasks. Conforming to the expectations > > definitely makes life easier, but with some effort you can use > > SwitchTower to deploy most configurations. > > yeah, I noticed. Just for me it is to strange to see most people then would > put generated files like the ones under script/ under svn... I am trying to > make sense of it.I put those in source control so I can easily move my app around. zing! It''s also nice for new rails versions. I can rerun rails and see accurate diffs on what has changed. Plus, the core team has done a great job of moving that rails code into libs in the latest beta gems. The core bits only have a few required lines of actual code. -- rick http://techno-weenie.net
Rick Olson wrote:> > accurate diffs on what has changed. Plus, the core team has done a > great job of moving that rails code into libs in the latest beta gems. > The core bits only have a few required lines of actual code.Does this mean that updating rails versions will be easier now? As it is we have to create a patch from two virgin rails installs (old and new versions), then apply the patch to our application. Thanks, Steve
On Oct 5, 2005, at 11:53 AM, Stephen Waits wrote:> Rick Olson wrote: > >> accurate diffs on what has changed. Plus, the core team has done a >> great job of moving that rails code into libs in the latest beta >> gems. >> The core bits only have a few required lines of actual code. >> > > Does this mean that updating rails versions will be easier now? As it > is we have to create a patch from two virgin rails installs (old > and new > versions), then apply the patch to our application.Well: 1. If you create a brand new app with the next release of rails, future updates will largely be a no-brainer, because there is a lot less code in your application that can change between rails versions. 2. If you have an existing app, you will have the option of completely updating your application to the new system (which is rather labor intensive to do, but VERY nice once done), or leaving things as they are in your current app. EVERYTHING WILL REMAIN BACKWARDS COMPATIBLE. You don''t HAVE to update your application, but note that if you don''t update your app to the new system, "rails ." won''t give you 99% of the new goodies, because the new goodies are now packaged in the rails directories themselves, instead of duplicated in each application. So, that''s the bad news. But the good news is that the new system is really, really slick. :) For those of you that don''t follow the new developments, the new system has the following changes: 1. There is a new Rails::Initializer. This takes alot of the work that your environment.rb used to do and pulls it into rails itself. 2. A side effect of #1: environment.rb is broken into two pieces, ''boot.rb'' (which should remain untouched) and ''environment.rb''. This allows (for instance) some rake tasks to load much more quickly by just using boot.rb when they only need the load paths, and not the entire environment. 3. Another side effect of #1: environment.rb looks a little different now. You can use the following construct to initialize which frameworks you want to load and what additional load paths you want. (It can do quite a bit more than this, too). Rails::Initializer.run do |config| config.frameworks -= [ :action_web_service ] config.load_path += %w(#{RAILS_ROOT}/app/services # {RAILS_ROOT}/lib/filters) end 4. Yet another side effect of #1: the stage environment files are now loaded via the Rails::Initializer and can access the "config" instance to manipulate the current environment. 5. The script directory has been stripped down considerably. Now, you''ll only see a "run" script in there. The other scripts now reside in rails itself, and are invoked like this: script/run console script/run server script/run process reaper and so forth. 6. The Rakefile has been simplified considerably. All of the standard rails tasks have been moved into rails itself. Your custom rake tasks can be put in lib/tasks in files that end with ".rake" (like switchtower.rake), and they will automatically be loaded when the Rakefile loads. (Among other things, this means that generators can easily add new rake tasks without having to modify the existing Rakefile. It also means you never have to worry about updating your Rakefile again, and trying to preserve your custom tasks.) There are probably many other changes to the environment that I''ve not mentioned. (I didn''t even touch on all the patches, fixes, and new features in the component Rails frameworks.) Anyway, when the next version is released you can be sure there will be a more detailed write up about these new features. We''ll also do everything we can to make the transition as easy as possible--as it is, your existing applications should continue to work fine, even if you don''t make the changes described above. - Jamis
Damn when is the next version out? I can''t wait...Having to "rails <directory>" each time was becoming a huge pain in the ass... _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
from which version are those architecture changes you mention present in rails? Duncan
On Oct 6, 2005, at 1:29 AM, Duncan Mac-Vicar Prett wrote:> > from which version are those architecture changes you mention > present in > rails?They''re not in a released version of Rails. Or did you mean "which revision"? Each of those changes was in a different revision--you''d have to go hunting through the changesets at http:// dev.rubyonrails.com to see precisely when each was implemented. - Jamis
On Thursday 06 October 2005 15:00, Jamis Buck wrote:> They''re not in a released version of Rails. Or did you mean "which > revision"? Each of those changes was in a different revision--you''d > have to go hunting through the changesets at http:// > dev.rubyonrails.com to see precisely when each was implemented.what I meant is if I can get those benefits now. I will not put my rails files in svn if I will have to upgrade them painfully later just because that cool move from scripts to lib is a feature not yet released. If it is available on released or beta gems, then it is ok. Duncan
On 10/6/05, Duncan Mac-Vicar Prett <dmacvicar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Thursday 06 October 2005 15:00, Jamis Buck wrote: > > They''re not in a released version of Rails. Or did you mean "which > > revision"? Each of those changes was in a different revision--you''d > > have to go hunting through the changesets at http:// > > dev.rubyonrails.com to see precisely when each was implemented. > > what I meant is if I can get those benefits now. > I will not put my rails files in svn if I will have to upgrade them painfully > later just because that cool move from scripts to lib is a feature not yet > released. > > If it is available on released or beta gems, then it is ok.Try the latest beta gems. You can tell what revision they were made from by the version number. I run my rails apps off svn though. Here''s a sample rake task and switchtower config I use: http://www.bigbold.com/snippets/posts/show/591 I specify which version in SVN in my switchtower recipe. When I deploy, it automatically does an svn export of that version and applies any custom patches I might be running on. One possible enhancement would be saving these rails versions in shared/rails/VERSION. This way if you have 5 revisions using the same rails trunk version, you only export once and symlink the directory. -- rick http://techno-weenie.net