How do you sanitize your source before doing a subversion commit?

Question

Sometimes when you're working with your local copy you might have configuration settings stored that you do not wish to commit and is impractical to ignore the file because it also contains application specific settings.

For example, a Django settings.py file contains both database connection details and project settings, such as which applications to load.

Is there a way to sanitize these types of files when they are committed? And is there a way to restore your own local settings during a checkout again?

My current environment is Linux and command line SubVersion

Answer 1

One way to address this problem is to keep the "standard" configuration file in a different file altogether, such as settings.py.example. In your working copy, you would copy settings.py.example to settings.py and work with the copy. If you need to make a change to the standard configuration, change settings.py.example and check it in. Otherwise, you wouldn't need to change it, and your modified settings.py isn't even in version control so it doesn't get noticed (you can include it in the svn:ignore property to make it even more quiet).

Answer 2

I use ignore-on-commit changelist.

This one seems to be specific to TortoiseSVN though. May not be available on the command line.

Answer 3

Here's how I avoid this issue. Typically I have development, UAT (user-acceptance test) and production configurations. Usually they exist side-by-side in the same directory (or perhaps separate dev/UAT/prod directories). These are all checked in and treated like source code. Consequently dev/UAT/prod database configs (for example) can be managed separately.

Development takes place pointing to the dev configs (however you choose to do that). Automated tests will run off the dev or UAT configs (depending on the project etc.)

Additionally, I provide a means to override by setting my system to check my home directory prior to loading those configs, and I can provide overrides which are truly personal. Often the overriding configs will only specify a subset of the variables, so the dev/UAT/prod configs can change and grow, and my personal config doesn't need to track the changes. My personal overrides aren't controlled via SVN or similar, since it's particular to what I'm doing at that particular time.