Page 1 of 1

Configuration files and CVS...

Posted: Fri Jul 29, 2005 12:37 pm
by nielsene
Does anyone know of good solutions for dealing with proper versioning of "configuration files" under CVS.

For instance you might have a file

Code: Select all

<?php
$DB_HOST = &quote;myhhost.com&quote;;
$DB_NAME = &quote;my_db&quote;;

$DB_UNAUTH_USER = &quote;db_unauth&quote;;
$DB_UNAUTH_PASS = &quote;foo&quote;;

$DB_AUTH_USER = &quote;db_auth&quote;;
$DB_AUTH_PASS = &quote;bar&quote;;
?>
Now lets say in testing, I change to using a different DB and/or users for some reason. I don't want to have to continually explicitly list the files to commit, rather I want to commit the whole tree, but exclude "trivially" changed configuration details. However I don't want to just ignore the whole configuration file, as I might need to add new variables to it, etc.

I also use CVS for code rollouts to my beta server, "cvs up" to bring it upto date. A staging server is used to test the actual patch scripts that will hit the production server.

If the "trivial" changes to the configuration file get committed, then of course "cvs up" overwrites the local configuration and I have to reconfigure everything.

Is there a workable solution to this?

Posted: Fri Jul 29, 2005 12:51 pm
by Ambush Commander
Have the transformation done transparently.

Code: Select all

switch ($_SERVER['HTTP_HOST']) {
  case 'www.myhhost.com':
    class Config_Wrapper extends Config_Production {};
    break;
  case 'stage.myhost.com':
    class Config_Wrapper extends Config_Stage {};
    break;
  case 'dev.myhost.com':
    class Config_Wrapper extends Config_Text {};
    break;
  default:
    class Config_Wrapper extends Config_Localhost {};
    break;
}
Edit - I got this code snippet from Advanced PHP Programming. Chapter 7 is about Managing the Development Environment.

Posted: Fri Jul 29, 2005 1:01 pm
by nielsene
That assumes a single instance of each "configuration". I'll often have 3-5 different local and beta test servers at a time, all with different configurations. If another developer joins the project you now have to add his configurations as well. This doesn't seem smart.

Posted: Fri Jul 29, 2005 1:08 pm
by Ambush Commander
Well then don't you need different configuration files for everybody? If there are overlaps, you can always use an extends. It seems smarter than having a bunch of non-CVS configuration files lying around, and then suddenly having a problem when you need to change the semantics of the configuration file.

Here's another suggestion if the first one still doesn't appeal: if you need to do small, temporary changes to the configuration file, you could always have the include tree look like this:

Code: Select all

include('config.php');
include('config_temp.php');
With config_temp.php overwriting the variables. You still have the original configuration, but the changes are in another file. This method runs into problems when there are immutable variables set in config.php.

Posted: Fri Jul 29, 2005 1:20 pm
by nielsene
Ambush Commander wrote:Well then don't you need different configuration files for everybody? If there are overlaps, you can always use an extends. It seems smarter than having a bunch of non-CVS configuration files lying around, and then suddenly having a problem when you need to change the semantics of the configuration file.
Well I guess what I'm asking is, for example PHP itself, there's the php.ini file. The "format" and default values should be under version control. However the paticular configuration changes of any developer should not get commit back the server. Expecting the developer to never use "cvs commit" without an explicit list of files seems fragile.

Ditto for the config.inc of phpBB, etc. All projects tend to have such a file; not all the options of possible configuration files get committed and you don't see config.inc.1.324523452 versions due to constant changes.

I think the solution probably is more of a business process type thing, than CVS or PHP hierarchy, but....

Posted: Fri Jul 29, 2005 7:01 pm
by timvw
You could do it as following:

dbconnect.php-example (sample file, and is in the repository)
dbconnect.php (this contains real credentials, and is in .cvsignore)

Posted: Fri Jul 29, 2005 7:04 pm
by Roja
You can tell cvs to ignore specific files for just such reasons.

Posted: Fri Jul 29, 2005 8:19 pm
by nielsene
timvw wrote:You could do it as following:

dbconnect.php-example (sample file, and is in the repository)
dbconnect.php (this contains real credentials, and is in .cvsignore)
This is exactly what I've been thinking about, but it still doesn't seem to play well when the format -example changes. You still have to change dbconnect.php. Otherwise you have the user looking at dbconnect.php and entering their config, never realizing the underlying format's been changes.

Unless your installer script is create dbconect.php from dbconnect.php-example?