Posted by Malcolm Dew-Jones on 07/15/06 02:14

JDS (jeffrey@invalid.address) wrote:

: There *is* a config file in the webapp hiearchy! Changing that file
: easily makes the webapp point all of its various pieces to the correct
: paths and files on the server.

: But the config file has to be different on the working copy than on the
: server!

: How can a version control system deal with this problem without me having
: to tweak the "live" config file every time I migrate the app from the
: Subversion repository to the live server?

I just keep separate config files for the different servers. Install the
app, and then install the appropriate config. I don't see how to avoid
"tweaking" the different config files at some point.

The development copy becomes your defacto "master" version. Note that the
versioning of this copy will track _two_ kinds of changes. "Maintence"
changes required for the (developmenet) server, and "upgrade" changes
required for the application updates.

Make sure that only one type of change is checked in at a time. E.g. if
you add a config variable (an upgrade change) and also change a path (a
maintenance change) then do two checkins, once to add the config variable
and once to change the path.

That way, later on it is easier to replicate the "upgrade" changes, simply
do a diff between the before and afters of the "upgrade" checkins.

Then apply those same changes to the various server configs.

If you get ambitious then use those changes as patches to automate the
upgrades of the server-specific configs. Apply the patches (in my example
to add the config variable), and then tweak the new values for each server
config (which you have to do at some point anyway).


Or - replace this whole thing with an install utility. That may itself
need a config file, but it will likely be simpler to maintain as you can
allow all sorts of defaults that the install will detect itself.

Or - a variation - use paths and variables in your development version
that are carefully chosen to be unambiguous in your code, and then a
script can easily _edit_ the master config file during the install to have
server specific values.

Or - include a config upgrade script with your application that will read
the old config variables and then spit out a new config file using those
values, perhaps prompting for any values that are new and cannot be
calculated.

$0.10

[Back to original message]