Best practice approach re freezing rails & SVN/Capistrano ap

Hi,

I’ve just 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 current best practice approach? If not what are most
rails
developers doing here re SVN and deployment approach?

Q2 - This approach seems to impact the deployment turn-around time
(given
the Capistrano / SVN approach), i.e. will take quite a while now to
deploy
each new version onto my hoster for testing. Am I missing something
here
perhaps?

Thanks
Greg

Greg H. wrote:

Hi,

I’ve just 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 current best practice approach? If not what are most
rails
developers doing here re SVN and deployment approach?

Q2 - This approach seems to impact the deployment turn-around time
(given
the Capistrano / SVN approach), i.e. will take quite a while now to
deploy
each new version onto my hoster for testing. Am I missing something
here
perhaps?

Thanks
Greg

I am on textdrive and have done exactly what you have suggested in your
post. When freezing rails it added the vendor/rails directory to my
application and from there i committed these files to my application
trunk on the SVN repository on the textdrive server. This did take
quite some time initially to get the files on the rails server but once
its done once thats it.

I noticed a rake deploy does take a little longer because the
vendor/rails files add some weight to the total files size but its only
an extra 30-60seconds in this case.

I dont know if this is possible but could you have the different
versions of rails in the shared folder or somewhere on your server and
then each app looks in this directory for the appropriate version of
rails based on whats in your configuration file? This would help as if
you have 50 websites and half are running 1.6 and the other half 1.2
then you will have 25 sites containg rails 1.2 in the vendor/plugins
directory and possibly 25 with rails 1.6 in the vendor/plugins
directory. For upgrading and maintenance this could be a nightmare, let
alone taking up space on your server.

On Feb 17, 2007, at 6:54 AM, John B. wrote:

directory. For upgrading and maintenance this could be a nightmare,
let
alone taking up space on your server.

Mike C. recently blogged about managing Rails versions w/ Capistrano:

http://clarkware.com/cgi/blosxom/2007/01/18#ManagingVersionsWithCap

Regards,
Craig