The decision to store settings.php in your version control system can be sticky. On one hand, there may be application-specific settings you would like to manage (perhaps the session lifetime, for example). On the other hand, it's a bad practice to store passwords in VCS, and some settings are host-specific. Perhaps you'd like to disable CSS aggregation on your development stage, or enable memcached only on your production stage.
Here is how I approach the problem:
I create a second config file, local_settings.php. Then I configure it to override anything in the main settings file by adding this to settings.php:
if (file_exists('./'. conf_path() .'/local_settings.php')) {
include_once './'. conf_path() .'/local_settings.php';
}
settings.php is placed in version control, and local_settings.php is not. Upon deployment, the local settings file is then symlinked to a shared directory in each server.
Here are some ideas for your own local_settings.php file:
// Database settings $db_url = 'mysqli://drupal:12345@localhost/drupal'; $db_prefix = ''; // Bypass almost all Drupal caches $conf['cache_inc'] = 'includes/cache-install.inc'; // Page cache $conf['cache'] = CACHE_DISABLED; // Block cache $conf['block_cache'] = CACHE_DISABLED; // Optimize CSS files $conf['preprocess_css'] = CACHE_DISABLED; // Optimize JavaScript files $conf['preprocess_js'] = CACHE_DISABLED;