SVN atomic commit how-to

Question

Where I am: Linux command line

The problem I have now:

Sometimes I couldn't make atomic commits(consisting all the modifications required for one particular ticket/task), because we have some files in the repository, which contents vary at local dev environments.

For example: database.xml(dbname, username, password etc.) I modify this file in my local env, and every time I need to make a commit/checkin I have manually list all the required files/folders for the commit(excluding this locally modified files).

Maybe it is wrong design decision and database.xml has to be deleted from the repository and changed for database.xml.template(stored in SVN), so this file won't be included to commit until you manually execute svn add for it? Maybe it is wrong approach - to store all this env dependent info in the repository - in that case we can break everything by commiting modified config, for example..

As I understand it, svn:ignore property couldn't help in this situation because it can be used only for files which isn't stored in repository..

How this problem can be solved?

P.S. I'm using Ubuntu and mostly pure command line for SVN.

Answer 1

You should store a template in the repository, but not the actual file that you need to modify locally.

This way you can rebuild a pristine file, if you need to, without risking storing a file into the repository that shouldn't be there.

And no, svn:ignore won't help you here.

Answer 2

The "standard" procedure for this is something like this (forgiving the svn syntax, I've been using bazaar lately):

echo config > database.xml.template
svn add database.xml.template
svn ignore database.xml
svn commit

Then on each person's dev machine

svn checkout
cp database.xml.template database.xml
...edit database.xml...

And when they commit:

echo foo > someotherfile
svn commit

the database.xml file won't be added to subversion.

Answer 3

Agree with keeping a .template in subversion and the real config, modified version only locally. What is important is that developers should never modify the real config file for other than personal configuration. That is, if a new option is to be added to the file, then it must be added to the .template file and then recreate their own config file out of it (maybe automatize rebuilding of config from the .template with a script to ease the work)