When using a large web application such as Magento, sometimes you need to make a large “instant” change to code, such as patching to a later version.
The suggested method is to effectively “reinstall” magento, that is to set up a fresh install, copy any user created modules, and upgrade the database.
If you use svn to manage your source code, this can prove a challenge, with seeming perpetual locks preventing you from committing the patch changes. The following method works on this basis:
1. Site is taken offline, the upgrade cannot progress (or won’t work) if the site is up and attempting to field requests.
2. The code base for the project will be reverted to the new patched version. You need to make changes to any core modules you’ve change again, which is why it’s generally a “very bad idea” to change core magento files. You may find that database errors crop up that you cannot easily overcome.
3. Any modules added later are then copied across.
4. Any files which it is safe to use the old version of, may be copied.
Of course, before applying this patch, you need to apply it to a test environment, and thoroughly test your site for things which break. In upgrading 6 “patches” worth of changes (18 months) there were a number of new features which required code and skin changes to function.
#Take down your site! If you do not, your database will get mangled!
#Back up database, because once you upgrade the site code the first request will trigger a pile of database changes
$mysqldump -uroot -p magento > livedump(date).sql
#backup magento directory
$mv /var/www/magento /var/www/magentobak
#unzip latest magento folder
$cp enterprise-1.11.2.0.tar-2012-01-05-07-40-21.gz /var/www/enterprise.tar.gz
$cd /var/www
$tar -xvf enterprise.tar.gz
#Change permissions to 777 (fine for test environment)
$chmod -R 777 magento
#Use a pre-created script to copy files that need to be copied such as modules and skins
#Access IP address of server to force database update (do it only ONCE!, otherwise it will try and upgrade the database once per request).
$lynx 127.0.0.1 #If you have a catch-all vhost setup
#Once this completes, your /var/www/magento directory will now contain a functioning(hopefully) upgraded version of magento. You can switch it out for magentobak and use mysql to roll back your database if the whole thing doesn't work.
But now subversion is broken, so what’s the solution to that?
This assumes you have rsync installed (and obviously, subversion)
$cd /var/www
#Make a folder to create your new mix of svn and the new live site
$mkdir svnworking
#Copy the root svn files
$cp -r magento/.svn svnworking/
$cd svnworking
#Update to latest version of the repository
$svn up .
#Tell svn to delete all files
$ls . | xargs svn delete
#Commit the changes
$svn commit -m "Armageddon!"
#Copy all files from live site to working directory
$rsync -av --delete --force --exclude=".svn" --exclude="log/*" --exclude="locks/*" --exclude="*cache*" ../magento/ ./
#Add all the files to repository
$svn status | grep -v "^.[ \t]*\..*" | grep "^?" | awk '{print $2}' | xargs svn add
#Commit files to repository
$svn commit -m "Patched magento to 1.11.2.0, code reset for all files"
Now this will do fine in a small environment. By doing this, you effectively cause anyone with a checked out copy untold potential grief.
This is actually a good thing, because they need to “start again” and make sure their code is going to work with the new version of magento. Obviously updating something like magento, is something you do in concert with your developers, rather than without their knowledge.
Coddswallop 