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 development environments.

For example: database.xml (dbname, username, password, etc.). I modify this file in my local environment, 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 a 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 environment dependent information in the repository - in that case we can break everything by commiting a modified configuration, 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 the repository..

How can this problem be solved?

PS: I'm using Ubuntu and mostly pure command line for SVN.

Answer 1

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 development 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 2

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 3

My 2 cents: First of all you need to make sure if there's any (easy) way to harmonize your paths for all devs involved to your project. This may be the same relative directory structure or some thin layer in your application which supports some shell vars or such like $home, %USERPROFILE% etc. This would be much more convenient over time than letting each dev deal with it's own unversioned configuration and that's what IDEs trying to provide as well.

In general, versioning config files is perfectly fine for me, it's simply time a dev spent to set things up and shouldn't get lost by accident.