How to un-version a file in SVN gracefully (without disturbing team members)?

Question

Variations of this question have been asked before, but it seems like the issue of disturbing other team members hasn't been mentioned. In existing posts (see How to "unversion" a file in either svn and/or git) the accepted answer is generally to run svn rm FILE or svn rm --keep-local FILE, and then set the svn:ignore property if desired. I've spent the last 20 minutes playing around with this (checking out a repo in two places, deleting a file from one, then updating the other, etc.). Here's what I found (I'm using SVN 1.6.16):

First of all, from what I can tell the --keep-local flag doesn't affect what happens to everyone else who is going to update from the repository afterwards. To them it looks the same as if you had just done a regular svn delete (none of the subversion documentation I have seen mentions this explicitly - maybe it should be obvious that you're still doing an svn delete operation and that "keep local" will only affect things on the local side, but it wasn't necessarily obvious to me).

So there are two cases - 1. team member A deletes a file that team member B had no local modifications in or 2. team member A deletes a file that team member B did have uncommitted local changes in.

In 1, after the delete takes place B's file has been deleted. He now has to recover it on his own (i.e. svn merge -rHEAD:XXX FILE; svn revert FILE to get version XXX of FILE back into the working directory and have it not be re-committed at next commit)

In 2, B sees a Tree Conflict on updating, and FILE now has a status of A + C with the message "local edit, incoming delete upon update" below it. At this point, I'm not exactly sure what the recommended solution is. What I did is copy FILE somewhere else, just to be safe, and then ran svn revert FILE. It ended up being unnecessary because FILE still exists unversioned in the working directory with all local modifications intact. But I don't know how much I trust this, as I've had my uncommitted changes erased by svn revert in other scenarios.

tl;dr: Is it really the case that only way to un-version a file in SVN is to delete it from the working directory of everyone else on the team and make them retrieve it themselves? Am I using --keep-local wrong, or missing another similar option?

Answer 1

You have to add all the files you are deleting to the ignore list ( easy with TortoiseSVN -> use Delete and add to ignore list option ) and commit that.

Now do the delete.

Another option is to do a svndumpfilter, as mentioned here: How do I remove a file from svn versioning without deleting it from every working copy?

Answer 2

Once a file is in the Subversion repository, it can never be completely removed. Sure, you can do a svn rm and commit to remove the file from the most recent copy of that branch, but the file is still there. Anyone checking out the revision before the file was deleted will see the file. And, you can easily find the deleted file by running a svn log on the directory tree.

There's not much you can do if you accidentally added a file that contains proprietary information (such as a customer's login and password) or is inappropriate, (we had one developer accidentally check in a gif he had in his workspace which later caused him to voluntarily leave the company before it became an involuntary act.).

Your choices are as followed:

• Take down the repository, then do a svnadmin dump. Use svnfilter to pipe the dump to a svnadmin load to create a new version of the repository sans the unloved file.
• Wait for Subversion 1.8 which promises to have an svn obliterate command. (Actually, checking the roadmap, it's not in version 1.8 anymore. Maybe 1.9?).

The --keep-local flag merely keeps a local copy of the file after an svn delete. The default is to remove the file locally from your workspace upon an svn delete.