CODEWITHSUNDEEP
svn
MonsieurBon
MonsieurBon

Reputation: 103

SVN: read-only/checkout-only file

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?

Upvotes: 2

Views: 731

Answers (4)

DeliveryNinja
DeliveryNinja

Reputation: 827

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.

Upvotes: 0

Luca Martini
Luca Martini

Reputation: 1474

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

Upvotes: 2

Adrian Smith
Adrian Smith

Reputation: 17593

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.

Upvotes: 0

tdammers
tdammers

Reputation: 20706

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.

Upvotes: 3

Related Questions