The OpenEdge Hive

Ah! Good points! And it makes me think: We should set up a Subversion repository with the entire oehive.org directory - all of the Drupal code and modules.

This will be handy when we need to hack Drupal itself, as I've already had to do in a very trivial way for totalfeeds.module.

Developers should work with new modules and configuration locally, before committing their changes.

We'll promote new changes to a test/sandbox, where everybody can work with common test data online.

I wonder if we could put the oehive.org subdirectory under Subversion control? We'd have to instruct Apache to disallow access to .svn directories. Then, we could use the command-line svn commands for applying patches and updates to oehive.org.

Then, as you say, we'd have devel -> test -> production, but with devel being a different local workspace on each developer's machine.

I was thinking that "http://sandbox.oehive.org/" would be good.

This is good Hive forum material. I hope you don't mind me quoting you. :)

Oh, hmm. I just thought of one reason that sandbox.oehive.org will be very important - people's local machines will be running different versions of Apache, MySQL, and PHP. That makes a big difference - I think a MySQL or PHP version issue was giving me some errors from that totalfeeds module I installed. If I only tried it local, I might not have seen it.

Jurjen Dijkstra wrote:
> It depends on the upgrade. For example, security upgrades can usually be
> installed directly, but code hacks are safer AND easier in a sandbox.
> For example, yesterday I have done a quick install of Drupal on my local
> computer for easier experimenting with the
> style.css. Because it is a local computer I can just edit the CSS file
> in TopStyle and immediately see the usually bad result, without having
> to upload the new CSS and have you wondering why the tabs jump up and
> down :-)
>
> We have already experienced that some settings cannot be reversed (like:
> existing projects break when you install Og and specify that each
> project is also a group). So, maybe we should indeed have a sandbox to
> try new modules or scary settings.
>
> When I hack PHP it's just trial and error, and I never get it right the
> first time. Maybe I should try the Zend development environment or the
> (free) PHP plugins for Eclipse, to get extra help and debuggers etc. But
> that also means I have to install Drupal on Windows.
> In that case, I'd have a local devel workspace, which you can't see. So
> if I hack something and want to show it to you, I would have to install
> my new code to some public domain for your feedback. That would mean we
> indeed have devel -> test -> production.
>
>