Ari Davidow wrote:
Yes, that is a beautiful explanation of git. I am still trying to think about the best way to deal with drupal configuration issues, to note module dependencies, and to deal with the fact that in a cms database, because of all of the auto-numbering dependencies, we have a model where we have successfully merged content and code--exactly where we didn't mean to be ;-). This may all clarify as I move forward.
I couldn't figure out a good answer to the question either -- "How do you do version control and concurrent operation/ development/ testing on a Drupal site?".
I became acutely aware of Drupal's version control/ concurrent development problems when I migrated from 5.x to 6.x. After several attempts, I ended up with the following process: back-up and check-in the production site, check-out and restore on a development server, figure out how to upgrade on the development server (uninstall modules, upgrade code and data to latest 5.x, fix database issues I likely created, back-up code and data, do a fresh install of 6.x, restore and upgrade data, back-up code and data, and forget about additional modules and their data), take the production site off-line (via htdocs link), repeat all the upgrade work on the production site, test, back-up, check-in, and put the production site online. It was tedious and time-consuming. I had to sacrifice functionality and associated data to succeed. (Fortunately, I didn't have much non-Core content in the first place.)
I view these version control/ concurrent development problems as a fundamental architectural flaw in Drupal. I suspect that the solution will require a utility for merging concurrent edits to the database, preserving referential integrity and accounting for code/ data structure/ schema versions. It's a non-trivial task, to say the least. Until this problem is solved, I will continue to run Drupal 6.x pretty much OOTB (with only the Core and Backup and Migrate modules).
I would be curious to learn of other CMS's that get it right.
HTH,
David