The solution was to create a simple class that looks for the existence of a file, environment.cfg, in the configuration directory. The contents of the file specify which environment to use. This file is not committed to Subversion each developer can specify their own environment without affecting anything in Subversion.

We added a few lines to our index.php file like this:

// Load the class which chooses the environment
require_once(dirname(__FILE__).'/../lib/helper/ApplicationEnvironment.class.php');

// Instantiate the class - specify the default environment to "live" (if there is no environment.cfg file)
$environment = new ApplicationEnvironment("live");

// Try and read environment.cfg
$environment->overrideFromFile(dirname(__FILE__).'/../config/environment.cfg');

// Create a configuration object using the chosen environment
$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', $environment->getEnvironment(), $environment->getDebugMode());

Note that the debug mode option is also set by the ApplicationEnvironment object. This is determined by the URL:

// in ApplicationEnvironment.class.php
    public function getDebugMode()
    {
        $debugAddresses = array("debug.example.com");

        return in_array($_SERVER['SERVER_NAME'], $debugAddresses);
    }

We could have used the environment.cfg file to specify this, for example on another line, but we also needed to specify debug mode on our live server so that if the site is accessed at www.oursite.com it is not in debug mode, but if it is accessed via debug.oursite.com then it is in debug mode (of course debug.oursite.com is http password protected).

CLI

Next we had the problem of setting the environment. We could of course rely on each developer to put --env=my-environment but it would be much nicer to have this done automatically. The solution was to create a simple script that resides in the application root directory next to symfony.php that looks something like this:

require_once(dirname(__FILE__).'/lib/helper/ApplicationEnvironment.class.php');

$environment = new ApplicationEnvironment("live");
$environment->overrideFromFile(dirname(__FILE__).'/config/environment.cfg');

$envSet = false;

foreach ($argv as $i => $arg)
{
    if (substr($arg, 0, 6) == "--env=")
    {
        $envSet = true;
        break;
    }
}

if (!$envSet)
{
    $argv[] = sprintf("--env=%s", $environment->getEnvironment());
    $argc++;

    $_SERVER['argv'] = $argv;
    $_SERVER['argc'] = $argc;
}

chdir(dirname(__FILE__));
require_once(dirname(__FILE__).'/config/ProjectConfiguration.class.php');
include(sfCoreAutoload::getInstance()->getBaseDir().'/command/cli.php');

It’s a bit of a nasty mess, but it works at least.

Download

ApplicationEnvironment.class.php

svn merge -c 1234 http://svn.example.com/myproject/trunk ./

Only to get:
svn: 'http://subversion.tigris.org/xmlns/dav/md5-checksum' was not present on the resource

I had absolutely no idea what it was on about, and a fair bit of Googling turned up nothing. Then, just for fun, I tried going one level up from my working copy and trying again:


cd ../
svn merge -c 1234 http://svn.example.com/myproject/trunk ./myworkingcopy/


And lo and behold – it worked. I haven’t the foggiest idea why, but it does. Any ideas anyone?

Using SVN v1.6.6

svn: Entry 'jquery-latest.js' has unexpectedly changed special status

It turns out that someone had created a symlink to whatever is the latest version of jQuery, which apart from being a somewhat dubious solution, should be fine.   However, it seems a Windows user then checked out this file and somehow changed it; either directly or by some strange Windowsy magic.   Anyway, the changed file was then corrupted and the result is the rather cryptic message above.

I tried to remove the offending file:

svn remove jquery-latest.js

But that resulted in:

svn: 'jquery-latest.js' is in the way of the resource actually under version control

Which was simpy resolved by using the --force command:

svn remove --force jquery-latest.js

I recreated the symlink, committed it and it seems now to be ok.