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

[arthur]

I think a really interesting project is the deploy module (http://drupal.org/project/deploy 
) which I think is an interesting abstract approach to this issue. It  
won't meet everybody's needs, and isn't functionally sufficient yet  
(for content at least), but is a good start, and worth starting a more  
serious conversation of how this problem might be addressed from the  
larger Drupal community. Some of the concepts that Greg has already  
got in place are critical for the staging issue. You can check out a  
talk Greg did on the deploy module at the Seattle Drupal User Group  
here: http://blip.tv/file/1033300

Anyway, food for thought.

a.



On Aug 9, 2008, at 2:35 PM, Dave Cohen wrote:

> Personally, I don't see how two DBs improves things.  In my  
> experience, nodes
> are often "configuration" as well as "content".  Trying to draw that  
> line
> somewhere is a mistake, IMHO.  You might draw the line where it  
> makes sense
> for your sites, but not someone elses.
>
> As you point out, the list is highly debatable.  I think it's  
> undecidable.
>
> -Dave
>
> On Saturday 09 August 2008, Zohar Stolar wrote:
>> As yhager proposed, having two DBs instead of one, may ease things  
>> a lot.
>> One DB will hold content: nodes, revisions, files, users...
>> The second DB will hold configuration: views, cck structure, modules,
>> variables... (this list is highly debatable).
>>
>> This will allow for two-ways updating - content is pulled down, while
>> configuration can be easily pushed up.
>>
>
>

---------------------------------------------------
arthur at civicactions.com