Greg, Tony, All,<br><br>Greg -- great point -- sometimes the settings.php file itself changes, so you can't assume that you can always use your old one. I like the emphasis on reading the release notes. So my follow up to Greg is: for people who install via "cvs update" -- do they need to read the release notes also? What happened with them on the 5.2 upgrade? Can CVS update a settings.php file correctly without overriding the db connection info?<br>
<br>Also re: Greg -- yah, it's probably cleaner to delete all the drupal files first (but not files and sites) before moving over a new install. On one site that I have we have a bunch of other directories in the Druapl directory (probably not a good idea) and this makes trickier when upgrading, need to pay attention to which directories are Drupal related, which not. That's why I thought the overwriting the old directories made sense in that situation. And thanks for the reminder not to use FTP. I presume SFTP is good enough, yes?<br>
<br>And to Tony... great description of a method that allows for a total/simple fallback when disaster strikes. However, your method still requires moving the old "sites" and "files" directory to the new install. It's a very clean approach, but still requires those files and sites directories to be moved around.<br>
<br>Shai<br><br><div><span class="gmail_quote">On 2/3/08, <b class="gmail_sendername">Tony Yarusso</b> <<a href="mailto:tonyyarusso@gmail.com">tonyyarusso@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What I've been doing lately is having the directory structure on the web host include version numbers. ie, my current docroot is drupal-5.7/ (exactly as the result of untarring gives you). When a new release comes out (after backing up the DB), I can just copy sites/ in and visit upgrade.php if necessary, without the harrowing experience of actually overwriting existing files or needing to worry about not deleting files that are no longer used. This way I just have to change the pointer in my web site's configuration to point to the new directory (either with DocumentRoot in apache or whatever panel interface your host gives you), and if things go badly, you can just switch it back and re-implement the database from the backup. If you want to be extra careful, you can configure the old site to actually use a backup of the database ahead of the initial switch, such that you can switch back without even the downtime of having to restore the database manually afterwards.<br>
<span class="sg">
<br>-- <br>Tony Yarusso<br><a href="http://tonyyarusso.com/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://tonyyarusso.com/</a>
</span><br>--<br>[ Drupal support list | <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.drupal.org/" target="_blank">http://lists.drupal.org/</a> ]<br></blockquote></div><br>