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?

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

Disparate

I agree with keeping a .template file in Subversion and the real configuration, modified version, only locally. It is important that developers should never modify the real configuration 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 configuration file out of it (maybe automatize rebuilding of the configuration from the .template file with a script to ease the work). – Internode

Yes, I'd have database.xml.template in SVN, database.xml.override in local checkouts and ignored, and a script to combine the two to produce database.xml. At least, I would if I had time to write the script ;-) Otherwise developers have to do a manual merge into databaes.xml every time database.xml.template changes. – Unclinch

In fact, if developers want to be really fancy, then can make database.xml.override a hard link to a file which they version control in their personal branch of the repository, so that personal config is controlled too. – Unclinch

In some contexts we use special keywords in the versioned file: USER for username, PASSWORD... then just a simple sed: "sed -e 's/USER/my_username/' -e 's/PASSWORD/my_passwd' config_template > config.xml" updates the file. – Internode

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.

Hospers

the actual command to make svn ignore database.xml would be "svn propset svn:ignore database.xml ." (as of svn 1.5.5) – Braddy

If I recall correctly using propset will override all the other svn:ignore's in place. You could try combining propget and propset or more easily just propedit and use the editor to add another line. – Internode

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.

Stygian

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.

Pious