tags:

views:

372

answers:

4

Like many projects, we deploy to many environments, QA, UA, Developer trunks, etc..

What is the best way to store sensitive configuration parameters in SVN? Or, should you not and just maintain a smaller unversioned file with credentials in it on the server?

Mainly, we do not want to expose production credentials to every developer.

A: 

I would not store configuration information in the repository at all. That way you don't have to worry about SVN trying to update the config when you update your source.

Adam Bellaire
A: 

I would agree with adam. If its not something that benefits everybody who works on the project, it shouldn't be under version control. If somebody checks out a copy of your code, will your personal project files help them? Probably not. It would most likely just clutter things up.

Jurassic_C
+6  A: 

I'd rather provide configuration examples than real config files. In my project there is setup.default.php file in root directory that every user need to copy as setup.php and amend to match local environment. Additionally, to prevent checking in back customised setup files there is a rule for it in .svnignore.

$ echo 'setup.php' > .svnignore
$ svn propset svn:ignore -F .svnignore .
Michał Rudnicki
+2  A: 

This is a problem I have run into as well. I think the answer is to check in a Template (such as you have with setup.php.default) and then use an automated tool such as Phing to make the push to development. If you use recognizable tokens in the setup.php file then Phing will be able to replace these tokens with individual server values. Also, an easy one step push live will be a helpful process to have.

jW