1. Dumping the database

In order to version control configuration settings, the database needs to be dumped in a fashion that is compatible with version control. This requires ensuring each insert is on its own line, and dumped in the same order. There also needs to be some extra care in preserving special characters.

While working on the site, other things are happening in the background. Essentially, you are being tracked. I call this "user data." For the purpose of development, this data does not matter and should not be saved in version control. There are configurable options for the dump script to control what data should and should not be tracked.

The configuration settings allow for two filtering options: full and minimal. Full would be all data you do not want tracked in the development process, while minimal would be used when dumping the production database. Minimal's default setting is to only filter cache and sessions. The dump script also supports a "none" option which would perform a complete dump with no filtering.

Using a database dump during development

Every time you make change and it is ready to be committed, you would dump the database. The default options are set to be optimized during development, so running the script with no options would dump to the development.sql file and filter it to not store user data. This dump process then becomes quick and easy, allowing you to install a module, configure it, dump the database and then commit the database configuration along with the module in one commit.

Keeping the database configuration settings in sync with the file system is highly valuable. It can help to quickly roll back to previous versions, and to remove commits. Bug tracking then becomes much easier as you can pin point a bug to an exact commit.