[development] Solving the dev->staging->live problem

[Kathleen Murtagh]

On Tue, Aug 12, 2008 at 1:33 PM, Dave Cohen <drupal at dave-cohen.com> wrote:
> <snip>
> While in your model as I understand it, I now have some variables
> (configuration, of the access control module) referring to my term ids
> (content).  So the line is crossed, I can't replicate the configuration
> unless I also replicate the content.  If I understand you correctly.
>
> I say this trying to point out that we can't simply divide Drupal's database
> into "content" tables and "configuration" tables.  Unfortunately is will
> never be that simple.  There are many examples like this where the line
> between content and configuration is fuzzy.

Dave, you are correct.  It is for this reason that I took the "merge"
approach.  I have been thinking very deeply about this topic for about
a year now, so I may not so quickly 'get' everything that is being
discussed as I'm likely in a rut in my thinking.  However, I feel then
my role may be best to at the very least provide what I have learned
for those who do 'get' the whole issue.

The way Drupal behaves, creating this fuzzy division between
configuration and content, makes this whole process difficult.  This
is the core of the problem, otherwise we could just copy tables back
and forth.  As I see it, UUID's would really only solve one problem of
the whole package - the sequences issue.  It's, of course, a great
problem to solve, however, there are other issues.

One of the things that likely needs to be supported in any system is
modifying content data in both development and production.  I think it
is a long ways off before this fuzzy division will go away.  In all of
the sites I have developed, I have in some way touched and modified
nodes during development of a site that has a live counterpart. Your
taxonomy example is great, as it can be both used for configuration
(access control) and content (free tagging) on one website.  Yikes.

If you allow modification of content data on both development and
production, then it opens a whole can of worms when merging that data.
The biggest issue is figuring out what is "new" content and what is
"deleted" content.  If I delete something in development, is that
deletion eliminated because it is considered "new" content from
production?  If I delete something in production, how do I push that
back to development without development inadvertently pushing it back
to production?  Then, ick, what if the same piece of content is
modified on both production and development (lets say the menus as the
most likely culprit)?

(please excuse me if this was a double post)

---
Kathleen Murtagh