SVN: How do I maintain my local config.blah file?

Question

On the SVN server, there is a file called config.conf. I have a local version called the same thing (in the same place). How can I make sure that my local config does not get overwritten, nor checked in?

While I'm here, is the answer different for a directory?

I'm using Tortoise SVN, but command line answers are cool.

Thanks!

[Sorry if this basic question has been asked before... I looked but didn't find it.]

Answer 1

TortoiseSVN has a nice answer for half of this problem: ignore-on-commit

This prevents you from accidentally committing "local only" changes, but it doesn't solve the problem on accidentally updating a locally changed file.

Check out this blog post for the detailed how to:

http://blog.baljeetsingh.net/2009/02/tips-tricks-svn-ignore-on-commit.html

Answer 2

1. exclude it from the repository with svn:ignore (you'll have to delete it from the repository first)
2. keep a copy in config.conf.default with placeholder values. You can keep the default copy in the repository.
3. use config.conf as normal - subversion won't see it any more

Answer 3

Thanks to everybody. I thought Eoin might be mad, but in fact it's true. You cannot ignore a file that is in version control.

According to the Tortoise docs

Ignoring Versioned Items

Versioned files and folders can never be ignored - that's a feature of Subversion. If you versioned a file by mistake, read the section called “Ignore files which are already versioned” for instructions on how to “unversion” it.

And from the SVN docs

I have a file in my project that every developer must change, but I don't want those local mods to ever be committed. How can I make 'svn commit' ignore the file?

The answer is: don't put that file under version control. Instead, put a template of the file under version control, something like "file.tmpl".

Then, after the initial 'svn checkout', have your users (or your build system) do a normal OS copy of the template to the proper filename, and have users customize the copy. The file is unversioned, so it will never be committed. And if you wish, you can add the file to its parent directory's svn:ignore property, so it doesn't show up as '?' in the 'svn status' command.

This is terribly annoying... I guess I'll just have to be careful with that file and make a backup copy of my own config (which I can ignore).

Thanks to everybody for your answers.

Answer 4

SVN will always think that that file is part of the repository if you name it the same and stick it in the same directory. Your options are

• Rename it (maybe write a shell script to mv config.conf config.conf.theirs && mv config.conf.mine config.conf and then run your app)
• Move it. Maybe add some logic to your app that checks for config.conf in a local, user-specific directory and then uses the default config.conf if none are found

Answer 5

You can add an svn-ignore: attribute to your local folder that excludes config.conf or even *.conf

But I believe, you'd have to completely exclude this file from SVN, i.e. if its already been checked in to the repo, you'll need to delete it rfrom the repository first

Answer 6

Ignoring the file should help you:

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-ignore.html

Answer 7

When there is a subversioning with configuration files, i've found very useful to have an entire trunk dedicated to it. Why? Most because you can simply have two local repository copy, one for local uses, one for remote chanings.

Like this:

/workdir/configuration [ is a link to /workdir/conf_local ]
/workdir/conf_local [ keep local conf updated but doesn't ovverride my settings ]
/workdir/conf_remote [ always updated with remote data, so I can commit changes ]

Answer 8

I don't know what sort of setup you have, or if this is applicable to whatever language you happen to be using, but this is the way I do it with websites and PHP.

First, you create default configuration, which probably has naive values that won't work for 90% of setups, but gives you a reference for what values there are, and what can actually be configured. This script is usually called 'config.default.php' or something in a similar vein. At the bottom of this script is something to the tune of:

if (file_exists("config.php")) require "config.php";

Simple logic. If there's a user override for the config file, then load it in, and let it override whatever it needs to. Then simply keep this user config file ignored via the methods already explained on all the development machines, and any production machines that keep a svn checkout for whatever reason. This is a very flexible setup, and similar procedures could be setup for most languages/environments.