next up previous
Next: 3 Administration Up: 2 Installation Previous: 2.6 After Installation

Subsections


2.7 Upgrading

Upgrading Scoop falls under two categories, upgrading the code, and upgrading your database. Upgrading the database is the hard part, so we reccomend backing up your site first. If its an upgrade between two minor versions of scoop (like from 0.6 -> 0.8 ) then you might even want to set up a test site, to test all the patches and work out all the bugs before swapping it in for your live site.


2.7.1 Backing up the database

Backing up your database is rather simple, as long as your site isn't too busy. Once you get above a few hundreds of thousands of hits a day it gets much more complicated :-) For most sites though, you can use mysqldump. It is used as such:

prompt$ mysqldump -u dbuser -p scoopdb > dump.sql
Now if you need to reinstall your database, you just drop and recreate the scoop database, and run dump.sql into mysql. i.e.:

prompt$ mysql -u root -p scoopdb
...
mysql> drop database scoopdb;
mysql> create database scoopdb;
mysql> quit
...
prompt$ mysql -u root -p scoopdb < dump.sql
Its not a good idea to do this on a live site however, many people will get errors. So you should take down your site for the time that you reinstall your old database.


2.7.2 Upgrading the code

Chances are you won't need that backup, but better safe than sorry, right? Now that you're all backed up, you need to update the scoop codebase. There are 2 ways to do this: get the latest nightly tarball from http://scoop.kuro5hin.org, or just use cvs (2.3.2). Install it in the needed directory, and now all you need to do is upgrade your database.


2.7.3 Upgrading your database

Now, you guessed it, there are two ways to do this as well! The first way is by hand, which is slow, but you have full control over what happens. The second way is to use the upgrade-db.pl script we include in scoop/scripts/, which will do all of that for you, and keep you posted on what is happening.

2.7.3.1 By Hand

Ok, so you want to do it by hand. 'cd' into the current patches directory of your scoop install. (Usually scoop/struct/patch-files/current). You might want 2 windows open in this directory, one to read the README file, and the other to apply the patches and scripts. Apply the patches in the order of the numbers on them, lowest number first. If there are patches and scripts with the same number, run the -pre script first, then apply the patch, then run the -post script. Example:

prompt$ mysql -u dbuser -p scoopdb < patch-00-Upgrades.sql
prompt$ ./script-01-pre.pl
... output ...
prompt$ mysql -u dbuser -p scoopdb <
patch-01-SiteControls.sql
prompt$ ./script-01-post.pl
... output ...
prompt$ 
Now there is no script-01 files currently, but that is just an example of how you would apply the patches and run the scripts.

2.7.3.2 With upgrade-db.pl

The easy way is to use this script. Run it from somewhere in the scoop tree and it should detect everything it needs, it will just ask you for what it can't figure out. Here is a short summary of its options:

-uscoop database user name
-pscoop database password
-dscoop database name
-hdatabase host
-odatabase port
-vverbose, talk about everything it does
-qquiet, don't tell me anything you don't *have* to
If you don't supply any of u, p, d, h, or o, it will prompt you for them. It will prompt you for the directory which contains the patch files when you run it.

But wait! How do you know what directory of patch files to use? Well, its rather simple once you understand how it works. the struct/patch-files/current/ directory will always contain all of the patches since the last point release. So if you are running 0.6-stable, then every patch to the 0.6-stable branch since its release will be there (its empty as I write this, by the way). If you are running a development branch, and upgrading from cvs often, then the patches will also be in the current/ directory, though there will be a bit more ( its actually not the same codebase as for the .6 or the other stable releases, so thats why there is patches in one current/ directory but not the other). When we release a new stable release, then we move the current/ directory for the development branch to a new name. Its named depending on which two stable releases it spans. So all of the .7 development patches will be in struct/patch-files/0.6-0.8/ when we release scoop-0.8-stable and current/ for 0.8 will be empty.

So thats how it works, you might want to read it again to be clear. Now onto the question, what patch-file directory do we use? Well, that depends. If you are upgrading from 0.6-stable to 0.8 stable, then the first time you run the script, you need to use the patches in the 0.6-0.8 directory, to get up to date with the .8 codebase, then every other time you run the script you would tell it to use the current/ directory.


next up previous
Next: 3 Administration Up: 2 Installation Previous: 2.6 After Installation