Magento white page on Admin System->configuration

I recommend using git over SVN. Easier branching and merging means that all of these points will go more smoothly for you.

Applying upgrades: Do this in dev. Make a branch (this is where git really shines), apply the patch files or even better, unpack a new Magento version and point it to your old database. No extensions yet. Open the admin in the new Magento installation an hope for the best. Upgrading between minor versions probably won't be a problem. You will probably have to reindex after all the new stuff installs. Do a commit once this is stable, then gradually bring into the branch your extensions and themes, make any code adjustments, then doing a commit after each step proves stable.

Environment-dependent files: .htaccess and app/etc/local.xml. I do a separate version for each: local.dev.xml, htaccess-dev local.staging.xml, htaccess-staging local.production.xml, htaccess-production

...and then make softlinks to them for each environment:

ln -s htaccess-dev .htaccess
cd app/etc/
ln -s local.dev.xml local.xml

and so on.

Restricting access to certain developers: I don't do this. However, you can develop a deploy strategy in git that lets a release manager decide what goes in and what doesn't.

Managing database changes: That's the trickiest part. We just use mysqldump from production, and have some ready-made "env-setup.sql" files for each environment. Something like this (your ids may vary):

UPDATE core_config_data SET value='http://magento.dev/' WHERE config_id IN (3,4);

I usually add some more instructions that will change payment gateways over to test environments, change outgoing emails, etc. Most of these you will find in core_config_data.

Remember that modules will usually make their own changes to the db, so applying a well-made module usually takes care of itself. In any case, never apply untested changes to prod, always do "rehearsals" on local and staging environments.

You can get the CMS (pages and static blocks) data out of the database by dumping and loading just the cms_* tables from whatever environment development was done on.

Good luck!

If you don't have proper permissions on the var/ folders, Magento can write its cache information to the system /tmp folder.

This can lead to a situation where you've changed the base URLs in the Magento database, cleared cache (manual deletion of all mage-?? folders in var/cache), (cleared APC cache if you're running the op-code cache), (manually disabled the compiler (1.4.x.x and later)) and the system still looks for the original site.

Most people who own their own server discover that the site magically starts working after fixing, clearing and resetting permissions and then rebooting the server. The server reboot clears /tmp of the Magento cache files and Magento finally starts looking at its own configuration to find where it's located.

Screen shots of this in action...

The Magento directory found in /tmp...

And the Cache living in that directory. Note the path -> /tmp/magento/var/cache

For finding that misplaced cache directory, if you can install n98-magerun, use the command n98-magerun.phar sys:info to get a basic system info listing with one item being Cache Directory location.