tags:

views:

40

answers:

4

What I'm looking for is this:

Say I have a file "database.conf" that has some default values for a database connection (dbname, user, password, etc). Everyone needs this file with different settings (eg. password). However, the local changes to this file should not be commited to the repository ever. So the file should be kind of "checkout-only". Is that possible?

+3  A: 

My usual solution is to create a set of config files with different names, and put them under source control, together with a script to copy the suitable one to the actual location; the config file that is going to be used however remains unversioned. For example, I could have a folder 'config_files', containing files 'dev.config', 'production.config', 'qa.config', etc.; my deployment scripts would take care of copying the correct script to the correct location (say, 'App.config').

You could even use hooks to automate this some more.

tdammers
About hooks: it's only possible to allow or forbid but not to change a commit in pre-commit, isn't it?
MonsieurBon
I was thinking along the lines of copying the correct settings file on checkout, but I'm not sure svn supports checkout hooks.
tdammers
A: 

The solution by tdammers is a good one!

I do it the same way, I have a set of files with different names like production.config or adrian_dev.config. I check them all in.

But then I have some config (e.g. in Apache config for mod_perl, or web.xml for Java), where I state what "environment" I'm working on, which is a string, e.g. production, so the program just goes to e.g. production.config without needing to have deployment scripts copying things around. If you need to make a change, it's nice just to check the config file in, without having to realize you're working on a copied file.

Adrian Smith
+2  A: 

You can create a database.conf.sample to be put in the repository, and set the ignore property for the database.conf file.

Luca Martini
This would be the easiest solution and I will probably do it this way.
MonsieurBon
A: 

If your using Maven you can create profiles for each different environment.

e.g

local.filter.properties dev.filter.properties beta.filter.properties

Now in the pom.xml you can define some profiles and point them to the different properties files.

        <profile>
        <id>dev</id>
        <build>
            <filters>
                <filter>src/main/filters/dev.filter.properties</filter>
            </filters>
        </build>
    </profile>
    <profile>
        <id>java</id>
        <properties>
            <idna.build.deployment.environment>JAVA</idna.build.deployment.environment>
        </properties>
            <build>
                <filters>
                    <filter>src/main/filters/java.filter.properties</filter>
                </filters>
            </build>
    </profile>

So when you build you select the profile that you want and in each profile you define the variables for the db user name password etc..

yourapp.db.username=UserDev
yourapp.db.password=password

and in your database.conf reference the property by its variable name

username=${yourapp.db.username}
password=${yourapp.db.password}

Now when you build your app you select the profile appropriate for the deployment your doing. This way the conf will get populated with the correct username and password at compile time allowing you to have just a single database.conf file.

DeliveryNinja