135

If I run svn rm file, the file is removed from the local working copy.

What I do now is:

$ cp file file2
$ svn rm file
$ svn ci
$ mv file2 file

How do I avoid svn also deleting the local file when using svn rm?

tshepang
  • 12,111
  • 21
  • 91
  • 136
Juanjo Conti
  • 28,823
  • 42
  • 111
  • 133
  • 1
    possible duplicate of [SVN Remove File from Repository without deleting local copy](http://stackoverflow.com/questions/542065/svn-remove-file-from-repository-without-deleting-local-copy) – Shai Jun 16 '14 at 13:38

4 Answers4

287

You want the --keep-local command-line option. This removes the file from version control without removing it from your filesystem.

$ svn rm --keep-local my_important_file

Note: The --keep-local only affects the svn rm of your copy. Other users may have their own local copy of the file deleted unless there is a conflict between their local copy and the repository due to changes they have made. This may not be the desired outcome. See comments below.

Richard Chambers
  • 16,643
  • 4
  • 81
  • 106
Andres Jaan Tack
  • 22,566
  • 11
  • 59
  • 78
  • 5
    Won't that still delete it from other people's systems once they update? – Nyerguds Nov 09 '15 at 08:20
  • 1
    @Nyerguds That's correct, as the svn rm is removing the files from the repository. In the event you wish to remove files from the repo, BUT keep them locally on your machine then you'd use the flag above. – Greg Hilston Feb 22 '16 at 13:31
  • 6
    @GregHilston As I said, though, that doesn't really help in actual multiple-programmer projects. There should be a way to just unversion the file everywhere. The most common case here are local settings files accidentally committed (very common in Java projects), but unversioning them shouldn't wipe other users' settings files. – Nyerguds Feb 22 '16 at 13:36
  • 1
    @Nyerguds Forgive me, but I didn't and still don't see you mentioned that is doesn't help in actual multiple-programmer projects. If you could point me to your other comments in this thread that'd be great, as I only see the one I am replying to. I'm not sure what you mean by "Unversion the file everywhere", can you elaborate on that? I'm using the command svn rm --keep-local my_file, as I infact accidentally committed an eclipse profile file and do not want others to pull it down but I myself, want to keep it. Does that make sense? – Greg Hilston Feb 22 '16 at 13:47
  • 5
    @GregHilston "actual multiple-programmer projects" was rather implied in "other people's systems". The problem is this: other people update, and get their settings overwritten. This is usually not too problematic, but annoying enough to want to resolve it. But at that point, when they have already overwritten the settings and now get an svn "rm" on update, it actually _removes_ the potentially-vital local settings file from their system, while it should just be unversioned so it can be configured to local settings again. – Nyerguds Feb 22 '16 at 13:52
  • @Nyerguds This action won’t wipe other people’s versions silently. If they have local modifications, they will get a conflict and will be able to keep their version. If they have been using the repo version, they can reload it from previous revision. – Melebius Nov 15 '17 at 14:21
  • 4
    Reloading an older file from the repository marks it as being from that older version, meaning an update will simply delete it again. There is no clean way to do this which doesn't require manual intervention on all machines in the project. – Nyerguds Nov 22 '17 at 11:32
13

Removing a file from SVN without deleting it locally nowhere is a common problem. One prominent example is the file .classpath in an Eclipse project. Putting this configuration file under SVN is marvellous as long as all machines used in the project have the same Eclipse and Java installation. Once this condition is violated commits start to break other Eclipse projects. This is the point one has to remove a file from SVN without deleting ist anywhere.

svn rm --keep-local .classpath

does the job perfectly on one machine and at that point in time.

Problem is other machines may lose that file (on update) or resurrect it (on commit). SVN's flaw is neither to handle --keep-local in the repository nor to propagate it to other working copies. Hence on all other machines above command has to be executed — best before any commit or update.

This, of course, will work 90%, at best. Deletes and re-versionings will happen out of a sudden. My solution is to have every machine, I have direct or indirect access to, do

svn rm --keep-local .classpath
copy .classpath .classpath-nameOfTheMachine
svn add .classpath-nameOfTheMachine

This is so outright ugly to be hardly called a "solution". Nevertheless it always allowed quick repairs of any later accidents.

Melebius
  • 6,183
  • 4
  • 39
  • 52
Albrecht Weinert
  • 146
  • 1
  • 2
1

for those who use GUI on svn, use below steps to remove a file from svn version control but retain it locally. enter image description here

Pawan Kumar
  • 114
  • 9
  • Thanks, did exactly what I wanted! Accidentally sent up some config files to my branch and just wanted to mark them as deleted in that branch without affecting my local working copy and this worked wonderfully. Was able to commit the deletions without affecting my actual code and didn't need to mess around with the CLI. – Peter Steele Feb 09 '23 at 21:15
-4

I do not have an answer to this precise question, but I do have an answer to a related question, which is how to remove all files (i.e. not a specific one) in a directory from version control without deleting them locally. This solution comes from a Scientific Linux implementation.

ls -a .svn

should show the svn directory that stores control data. Simply:

rm -r .svn

will get rid of this directory. Then typing:

svn status

will produce a 'warning: this directory is not a working copy' error, because it is no longer under version control.

I hope this helps.

cjames
  • 1
  • A related question? Removing a file and removing the whole working copy are totally different things IMHO. – Melebius Nov 15 '17 at 13:21