Re: controlled files to be deployed to different environments

[Paul Sander]

I can think of a few ways to do it.

1.  Use your packaging/deployment system to distribute many copies of the
    file but install the proper one according to the selected configuration.

2.  Keep a collection of these files under source control, and use build
    targets to rename them as needed.  This was your suggestion.

3.  Ship a sample configuration file and version control the proper file
    in the running environments.

4.  Ship many configuration files but use an uncontrolled indirection layer
    to point to it.  (This can be in the form of a pointer file or symlink
    that points to the "real" configuration file, or a command line argument
    given to the application, or perhaps some other method.)  The indirection
    layer could also be installed as in item 1 above.

5.  Abstract out the features of the configuration file and use a macro
    preprocessor such as m4 during install time to identify the target
    platform and generate the proper configuration file.  The application
    could be modified to invoke the preprocessor and interpret its output.

My personal preference is to combine methods 4 and 5:  Have the application
invoke a macro preprocessor and interpret its output.  The preprocessor's
input is specified by command line argument or environment variable, backed
up with a default that's computed based on the location of the installed
binary.

--- Forwarded mail from address@hidden

For one of my projects I have a configuration file, say mail.properties,
which I'm versioning in CVS. The contents of this file will be different for
different environments, though. For example, the mail server for my
development environment is different than for my production environment.

Currently, I have the development version controlled, and when my project is
ready for deployment to production, I manually change the contents and send
it off (but don't change the version in CVS). I would like suggestions on
ways to control different versions of the same file. So far, the best idea
we've come up with is to give each version a different extension and then
use our make utility to pull the right one and rename it, so
email.properties.dev becomes email.properties. Any other suggestions?

--- End of forwarded message from address@hidden