Moving a site from an old version control set-up using SVN to Agaric's new Git-Capistrano glory

Agaric salutes you, Stefan!

And without further adieu, the steps to move a Drupal 5 site from one of our legacy approaches to development and deployment using version control to Stefan's Git-Capistrano set-up (and upgrading to Drupal 6 in the process).

Moving CarlitosNY.com into the new system (and Drupal 6 while we're at it).

On the production server, find where it's hidden...
ben@agaricdesign:~$ locate carlitos

Ahh, there it is, let's take a look at the database settings:
vi /var/www/drupal-5-live/sites/carlitosny.com/settings.php

$db_url = 'mysql://eliana_live:5V8cH.WBKEUVBd89@localhost/eliana_live';
$db_prefix = 'carlitosny_com_';

I'm still in my home directory, so I can just dump the database there, getting the user, database, and password information from above:

mysqldump -u eliana_live -p eliana_live > carlitosny_5_backup.sql
Enter password:

I could have compressed it before sending it to the test/staging server, but such is life:

scp carlitosny_5_backup.sql ben@server.grassrootsconnection.org:~

So, back at the test server...

Here's a bonus how-to for you...

Remove the database table prefixes:

sed -i 's/carlitosny_com_//' ~/carlitosny_5_backup.sql

(Unix/GNU-Linux is so cool...)

On with the show.

Import the old database

mysql> show databases;

drupal_carlitosny

is there.

mysql> USE drupal_carlitosny
Database changed
mysql> SHOW TABLES;
Empty set (0.00 sec)
mysql> QUIT;
Bye

Good. Now import the backed-up copy:

mysql -u root -p drupal_carlitosny < ~/carlitosny_5_backup.sql
Enter password:

The new test site has database settings values, but somehow the user was not created.

vi /var/www/carlitosny/drupal/sites/default/settings.php

$db_url = "mysql://carlitosny:hRBrJ9VQ@localhost/drupal_carlitosny";
$db_prefix = '';

So I added carlitosny through phpmyadmin and granted all privileges to drupal_carlitosny.

Upgrading from Drupal 5 to Drupal 6

Changed update access from FALSE to TRUE:

sudo vi /var/www/carlitosny/drupal/sites/default/settings.php

<?php
/**
 * Access control for update.php script
 *
 * If you are updating your Drupal installation using the update.php script
 * being not logged in as administrator, you will need to modify the access
 * check statement below. Change the FALSE to a TRUE to disable the access
 * check. After finishing the upgrade, be sure to open this file again
 * and change the TRUE back to a FALSE!
 */
$update_free_access = TRUE;
?>

And went to:
http://carlitosny.agariclabs.com:81/update.php

Got a few regular old errors output by drupal_set_message (below), but the updates all succeeded

# user warning: Table 'drupal_carlitosny.views_view' doesn't exist query: SELECT DISTINCT v.* FROM views_view v in /var/www/carlitosny/drupal/sites/all/modules/views/includes/view.inc on line 1203.
# user warning: Unknown column 'serialized' in 'field list' query: SELECT data, created, headers, expire, serialized FROM cache_views WHERE cid = 'views_default_views:en' in /var/www/carlitosny/drupal/includes/cache.inc on line 26.
# user warning: Unknown column 'serialized' in 'field list' query: UPDATE cache_views SET data = 'a:8:{s:15:\"comments_recent\";O:4:\"view\":22:{s:8:\"db_table\";s:10:\"views_view\";s:10:\"base_table[.......]

First step, log in and tell it a where to find the theme now... err, actually, give it a new theme.

http://carlitosny.agariclabs.com:81/user?destination=admin/build/themes

Before modules could be installed using the (new, experimental) run-outside-the-site Drush, we had to go to admin/build/modules and enable the (now-core) update status module.

Oh, and move the files, I always forget. From the production server:

scp -r /var/www/drupal-5-live/sites/carlitosny.com/files
ben@server.grassrootsconnection.org:~/carlitos_files

Back on the staging server, we can see that files is still empty, so we go ahead and move everything in:

ben@server:/var/www/carlitosny/drupal/sites/default$ ls files/
sudo mv ~/carlitos_files/* files/
ben@server:/var/www/carlitosny/drupal/sites/default$ ls files/
Rtronika.jpg  Volante - Liza Maytok.jpg  carlitoszen_favicon.jpg  dirty boogaloo.jpg  images
ben@server:/var/www/carlitosny/drupal/sites/default$

Did this on the test server, but using the localhost Capfile should have worked:

ben@server:/var/www/carlitosny$ sudo dbscripts/dump.php

Dumped the database to development with full filtering options.

cap agaric:git:commit

git pull

Rake can make a vhost for you (this will almost certainly be automatically done already in the future), and then you can edit it to add in the domain names ( example.com for the server and www.example.com for the alias)

rake vhost
vi vhost
git add vhost
git commit -m "vhost updated"
git push agaric +master
cap -S stage=production agaric:update
cap -S stage=production agaric:enable

Needed a git repack in there apparently once. Or maybe it was a dangling commit Stefan made.

After a change to vhost needs to be made...

vi vhost
git commit -a -m "vhost updated"
cap -S stage=production agaric:update
cap -S stage=production agaric:enable

cap agaric:db:dump
cap agaric:git:commit
git pull agaric master

Super-helpful Capistrano Hint

Get a list of all available tasks with cap -T:

cap -T

Resolution