SVN: Ignoring an already committed file

Question

I have a settings file that is under version control using subversion. Everybody has their own copy of this file, and I need this not to be ever committed. However, like I said, there is already a copy under version control. My question is: how do I remove this file from version control without deleting everyone's file, then add it to the ignore list so it won't be committed? I'm using linux command line svn.

Answer 1

Make a clean checkout, svn delete the file and add the ignore. Then commit this. Everyone else will have to take care (once) that their local copy isn't deleted on the next svn update, but after that, the local file would stay undisturbed and ignored by SVN.

Answer 2

if you remove the file from version control, how does a developer new to the project (or the one who accidentally deleted his local copy) get it after initial checkout? what if there are additions to the settings file?

i would suggest the following: keep a default settings file (with no passwords, hostnames, connection strings, etc.) in svn, name it something like settings.dist, and let the code work with a copy of this, named settings. every developer has to make this copy once, and can then work with her personalized settings. if there are additions, add them to settings.dist - everyone else will get them with a update and can merge then into her personalized copy.

Answer 3

simply define a file containing settings that will override the default ones. This file is not checked into Subversion and each developer is responsible for maintaining this file according to their environments.

In an Ant-based world, you would have the files:

settings.properties
settings-local.properties (ignored for Subversion)

and in your build.xml file

<property file="settings-local.properties"/>
<property file="settings.properties"/>

For those who couldn't connect the dots:

1. modify the build.xml file like proposed
2. set the setting-local.properties as ignored
3. in an init target of your build, copy the settings.properties to settings-local.properties
4. wait a couple of days until everyone had the chance to run this target
5. delete the setting.properties from Subversion

Voila, every developer has its own setting-local.properties and everything was done automatically (and no developer lost his or her settings, which happens if you brutally delete the file from Suvbersion and there is no "Everyone else will have to take care...")

Answer 4

[[ I'm new to subversion, so maybe this doesn't make sense. marking this as wiki -- if you know the right answer, please APPEND in the later section ]]

Couldn't you have a custom set of checkout steps so each user gets a different settings folder?

$ svn checkout http://example.com/project  project
..
$ dir project
original_settings\     folder1\     folder2\ 
$ svn checkout http://example.com/project/aaron_settings project\settings
..
$ dir project
original_settings\     folder1\     folder2\    settings\

Or for new users

$ svn import project\settings  http://example.com/project/aaron_settings

What I'm getting at is you want each user to have a custom view of the repository. In other version control systems, you could set up a custom listing of which projects you were using and which you weren't and which you put in odd places.

Does this work in subversion? The above code looks really risky, but maybe i'm doing it wrong.

WIKI:

(nothing yet)

Answer 5

After you delete the file, your users will have to recover the file from the repository using svn export.

$ svn export -r x path ./

Where x is a revision where the file existed before it was deleted, path is the full path to the file, and ./ is where the file will be placed.

See svn help export for more information.