Versioning Use Cases

To keep a production joomla website up-to-date

Rules

The code modification of an extension ONLY makes code changes (configuration changes ALSO make database changes)
The addition/deletion of an extension makes code AND database changes
Because production is changing (mostly w/respect to the database) and can be changed (w/respect to the code), it must live on an active release branch of version control, so that changes to extensions (adds/deletes) can be merged back to the trunk to maintain synchronicity.
Whenever committing to the repository, the database for that codebase, must also be committed so that any release version can be reproduced at any time.

Test on the dev machine and then actually install/configure on the (necessary to disable?) production site. (late at night)
Merge code from production branch to trunk
Import production db snapshot to sym_dev

Test on the dev machine and then actually uninstall on the (necessary to disable?) production site. (late at night)
Merge code from production branch to trunk
Import production db snapshot to sym_dev

Major modification (Like forcing an extension to do something beyond what it was intended to do, e.g. modifying myblog to allow separate blog instances that will take a few days to complete)

Make sure wc has no modified code (we're going to use this feature to keep track of our code changes)
Make mods in wc, test and merge to production branch

Minor modification (Like adding a few lines of code to support some small feature/fix that will only take minutes to hours to complete)

Make sure wc has no modified code (we're going to use this feature to keep track of our code changes)
Make mods in wc, test and merge to production branch

Install the new extension on production. Merge to trunk. Now trunk has the new component (in code only)
Database tasks before modifying any code.

If there was something created in the dev process (like forms) that cannot be backed up, then maybe copy/paste to prod is the best way...whatever avoids needing to merge db...We do not want to do that.
Only do the following in the extreme cases

There will need to be a merge between the dev db and the most recent production backup at the end of development/testing using this approach