24

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.

bkildow
  • 5,143
  • 4
  • 29
  • 37
  • possible duplicate of [svn ignore without deleting files?](http://stackoverflow.com/questions/951032/svn-ignore-without-deleting-files) – tchrist Sep 03 '12 at 02:26

6 Answers6

22

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.

David Schmitt
  • 58,259
  • 26
  • 121
  • 165
  • How (as "everyone else") do you prevent the delete on update? – David Moles Nov 14 '12 at 19:25
  • Move it away before running the update. Copy it back afterwards. – David Schmitt Nov 15 '12 at 10:45
  • 1
    How come there isn't an easier way of doing this? Can someone explain? – DaveS May 13 '13 at 00:12
  • @DaveS: Easier in what way? – David Schmitt May 14 '13 at 11:31
  • 3
    well, easier as in not having to coordinate (doing the whole moving the file away and copying it back) with everyone else that uses the repo. – DaveS May 14 '13 at 17:24
  • 1
    @DaveS: Even if this were fixed, so that an `svn update` across this change wouldn't delete the file, the file is still in danger of being clobbered by jumping back in the history (overwrite with old revision) or switching branches. I guess that nobody thought this "feature" valuable enough to step up and implement it. – David Schmitt May 15 '13 at 08:49
15

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.

Melebius
  • 6,183
  • 4
  • 39
  • 52
ax.
  • 58,560
  • 8
  • 81
  • 72
1

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.

matpie
  • 17,033
  • 9
  • 61
  • 82
0

I have a similar issue. In my case it's an auto-generated user settings file (visual studio) that was accidentally checked in very early in the project. While just deleting it might work, it seems more correct to have it removed from the history, as it was never supposed to be in there in the first place.

I came across this, which might be a new feature since this question was originally posted 7.5 years ago:

https://stackoverflow.com/a/6025750/779130

Seems like an idea would be to:

1) create a dump of the project.
2) filter the dump using `svndumpfilter` to exclude the unwanted file(s).
3) load the dump as a new project.

This might be the only way to completely get rid of the file. In most cases the "delete and ignore" approach might be good enough.

Community
  • 1
  • 1
Svend Hansen
  • 3,277
  • 3
  • 31
  • 50
0

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...")

Vladimir
  • 6,853
  • 2
  • 26
  • 25
-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)

Sander Rijken
  • 21,376
  • 3
  • 61
  • 85
Aaron
  • 3,454
  • 23
  • 26