[PLUG-Devel] SVN and conf files

[Craig White]

On Wed, 2006-12-06 at 01:47 -0700, der.hans wrote:
> moin moin,
> 
> at work we have a code base that has everything hard-coded. Major suckage.
> I'm working on fixing it.
> 
> We also have recently moved to Subversion, which is good.
> 
> We now have dev and prod environments. We might someday get to use the
> stage environment as well. The configuration we need to use in each
> environment differs somewhat. I'd like to keep the configuration files in
> SVN as well since the basic format stays the same, just some of the values
> are different.
> 
> Any suggestions on a good way to keep the base structure the same and yet
> have slightly different values?
> 
> I could throw the config files in branches and use softlinks to put them
> in place. I fear this would lead to the config files getting out of sync.
> 
> I could tokenize the things that change and build the config files in each
> environment from a skeleton that's in SVN. Twould be good to have a
> trigger hit the build mechanism every time a config skeleton changes. Yes,
> require specific OK for the trigger in prod :).
> 
> I could come up with a config file format that allows scripting and then
> just use programming structure to determine the proper config for the
> machine. Yuck.
> 
> I could add a config stanza for each machine in the config files and then
> use the hostname or environmental variables to figure out which stanza to
> use. I guess this would be OK, but again I think it leads to configs
> getting out of sync.
> 
> I could just get a job at a company that understands and values config
> files :). I'd still need a solution to this dilema, though.
> 
> Oh, BTW, I need to add config files to shell scripts, PHP scripts, Perl
> scripts, Java programs and I'm not sure what language a couple of the
> tools are written in, but probably one of those.
> 
> Some of the scripts get config info from XML files.
> 
> A couple get configs from XML files that override the configs written in
> other XML files.
> 
> Thankfully our diverse array of Oracle environments were all homogenized,
> well except the one in dev disappeared again today...
> 
> Our MySQL environments are, um, varied. They copy data back and forth and
> are all, in some way or another, different.
> 
> Mostly, the DB issues are handled by the configs for the tools, but I
> thought I'd mention them in case anybody had any gotchas they wanted to
> bring to my attention.
> 
> happy happy config config,
----
the way that I have been handling this with rubyonrails is config files
themselves are excluded from svn (actually ignored)

for example...
rails_root/config/database.yml is ignored
rails_root/config/database.yml.office is committed normally
rails_root/config/database.yml.home is committed normally
and I just copy and likewise ignore...
rails_root/config/database.yml.one_of_them
rails_root/config/database.yml

Craig