Drupal Source Control Strategy?

Question

In standard php or source code based projects we easily keep all of the code in SVN and each developer can checkout their own copy and collaborate on the same code.

<

Answer 1

Unfortunately, there just isn't a good/simple solution here. The problem is an unfortunate side-effect of the architecture of not just Drupal, but all framework-type CMS's where applications are defined as much through configuration (i.e. data stored in the db) as through source code. Neither of the two options for managing configuration data are great. The first is what you are doing: define a single db as canonical (i.e. the production db) and have developers work locally with a snapshot of the production db and "merge" new config info into the production db via manual configuration through the production site admin interface. In the case of well-defined subsystems - i.e. Views - you might be able to take advantage of import/export features developed to ease just this kind of configuration migration. The second option - i.e. the automation I think you are looking for - is difficult but could be worth it - or required - for large projects with the budget for complex project automation: dive deeply into the system/module db structure and develop custom scripting to merge new configuration data at the table/record level into the production db, say, as part of a nightly "build" of the latest db. Afraid there just isn't any in-between solution.

In terms of version control for historical tracking of the configuration data, a module like backup_migrate allows you to perform automated SQL dumps of the db. You can choose which tables are dumped by defining a backup "profile" and could create one that left large content, logging and caching tables (e.g. node, cache_content, watchdog) out of the dump so you were left with a more manageable chunk for versioning. Some simple scripting on the server or elsewhere could grab the latest dump and add it to your respository.