Re: handling config files

[Tobias Brox]

[raptor - Sun at 04:37:54PM +0200]
> so U set those variables in config file /sites/config/Config.pm and this
> file is under CVS control, what is the problem here. Both Config.pm must be
> different ('cause they represent different file structures), but U still
> want when u add new Variable in the DEV-Config.pm it to be updated on the
> Production-Config.pm, on the other hand U want to preserve the values that u
> have on Production server, but not edit them by hand every time u make
> Update on the Production server.

I've been in similar situations myself - having a Config.pm that contained a
lot of common information, but some few truely local variables.  I've tried
dealing with it in different ways.

I'll first comment your options, then add some more.

> So what u do in those cases !?
> 
> 1. Copy temporarily this file off-site, make "cvs update", return it back
> (overwrite dev-version), manualy edit it if some new stuff are added

You can do it easier, just edit your local changes into the file, never
commit it, and forget about it.

When you do a "cvs update", no local changes will be undone.  Changes in the
repository will be merged into the local file.  Of course, there might be
conflicts, that's the only bad thing.

In the repository, you should have a generic file; don't fill in any local
information, leave everything either blank or with sane default values, or
with weird example values.

This solution will probably be the best if you're not afraid of conflicts,
if the file is not updated too frequently in the repository, and you don't
need to have version control on local configurations.  

It will probably break a bit with my previous suggestion about never editing
things directly at your PrimaryDevServer, but always update them through the
CVS.

> 2. make a Selective update dir by dir (not the whole repository at once, so
> that this config file is not touched)

Sounds like a nightmare.  I'd propose an alternative; have all
configurations in a separate directory, and use a different (local!)
$CVSROOT for the configurations.  I haven't tried this myself, but I'd
daresay it's perfectly possible.  This is the best option if you want to
have version control on local configurations, and don't need/want to share
it with others.  

The local configuration directory, filled in with default values, should
probably be placed there in the first place by some installation suite
(Makefile, typically).  The default values should probably be stored in the
central repository.  I.e. have a configuration directory called "Default",
and another called "PrimaryDevServer", and have some logic in the script
choosing the right configuration file.

This might be the best option if the software is to be distributed widly,
and you want to attach default configuration, maybe some example
configurations, and some local configurations as well in the main CVS, but
also give people possibility to have their configuration in local CVS
repositories.  This solution is not so good if you make a lot of changes in
the configuration file setup that needs to be copied into each of the
subdirectories.

> 3. Remove this file from CVS control and copy it manualy when needed (very
> ugly u may loose usefull info)

That is another option.  It doesn't need to be so ugly, because you should
probably make an installation kit where a Makefile will create those local
files for the user (as mentioned in #2).  This is the best option if you
want to make some software that is to be distributed widly, and neither you
nor the other users will need CVS control on their local configuration.

So ... some more alternatives:

4. Make a template file, and a Makefile that creates the configuration file.
In a perl script, the first line (typically #!/usr/bin/perl) should also be
replaced by the Makefile.

We did have such a solution, with all configurative variables in the
Makefile, and duplicated in some Config.pm-file.  For me, this solution was
horrible.  For one thing, the configuration trouble was just moved, the
Makefile would need to be edited instead of the Config.pm-file.  When
debugging and developing the script as well as the config-file, I'd like to
work directly with the script, not on the templates.  This solution was both
inefficient and cumbersome for me, though it could probably be solved
through some clever scripting.

5. Make separate branches for each local configuration.

I've tried that too.  I don't remember why, but this solution did cause some
frustration for me.  I think my problem was that I branched the whole
project, not only the configuration file.

This is probably the best thing to do if you want all the local
configurations to be in the same CVS repository.  This solution is also
perfectly compatible with my earlier suggestion about never editing files at
the PrimaryDevServer, but always update it through CVS.  The local branch of
the configuration can be checked out in a separate directory at any of the
work stations, edited, committed, and then automaticly updated at
PrimaryDevServer.

To handle branching, you will need to read quite a bit in the CVS
documentation, and you will need to keep your head straight - it's probably
worth it anyway, if you're to use CVS a lot, you'll need to handle branching
sooner or later.

6. Now I'll try to describe what I did for my project ... it's a bit perl
specific, and it certainly became a bit complex.  I think it's the best way
to do it if the configuration is quite complex, lots of configuration
variables depends more or less on each other, and most of the default values
can be used at any site, but some few things needs to be overridden.

I made a very short script - like five-six lines - telling where the perl
executable was located, where the libraries were located and what
configuration file to pull in.  The script itself would then pull in one
library and the configuration, and start the "main"-sub.  I made a template
for this script, the script itself was generated through a Makefile.  I
guess ExtUtils::MakeMaker can be used for dealing with the Makefile and
those few configurations.  So, what configuration file to use (and what
directory to find it in) is written in one tiny file that probably never
will need any serious updating.  It's freely up to the local administrator
whether he wants his local configuration within the main repository, or in a
separate directory which he eventually have local version control on.

I made the configuration itself semi-object-oriented, so I had a
"configuration object" that was instanciated in the abovementionated script.
The very most of the configuration was global variables, some few things was
defined as methods under the configuration object.  The latter must be the
most Right way to do it in an object oriented world - but, I think I
discovered it was easier to use global variables after all.  The variables
was, by default, initiated through methods.

So, I would have a method InitiateConfig, which called other methods - like
InitiateLogging, InitiateDirectoryStructure, etc.

The local configuration file would inheritate the global configuration file
directly or indirectly, consist only of some few lines overriding the
necessary variables _or_ initilization methods either directly or
indirectly.

Some small example file would be provided in the central CVS repository, and
local managers (with permission to write to the repository) would be able to
add their configuration on their own liking.

Since the local configuration file can be in the repository, the solution is
perfectly compatible with my suggestion about updating PrimaryDevServer only
through the CVS.

--
Unemployed hacker
Will program for food!
http://ccs.custompublish.com/