Delete file with all history from svn repository

Is there any way to delete file from svn repository including all its history? This issue emerges when I want to get rid of large binary file residing in repo.

I know only one approach that might help in this situation:

1. Dump all repo with the help of svnadmin utility.
2. Filter dumped file with grep. Grep should use filename and writ开发者_如何学Goe in to the other dump-file
3. Import last dump-file with svnadmin

But this is too complicated and unreliable. Maybe there is another solution?

This has recently become much more straightforward with the command svndumpfilter. Details are available in the subversion documentation here. Basically, to avoid conflicts (explained here), it takes a repo dump and redoes each commit, either including or excluding a given file prefix. Basic syntax:

svndumpfilter exclude yourfileprefix < yourdump > yournewdump

Exclude is probably what the question asker is looking for, but you can also use include to, say, extract a subtree of the repo so as to spin it off as its own repository.

The latest revision of subversion in subversion (very meta) can also take glob patterns. I recently had to remove all pdfs from a repo and it was very easily done like so:

svndumpfilter exclude --pattern '*.pdf' < dump > dump_nopdfs

Further usage information can be found by calling svndumpfilter help and svndumpfilter help exclude.

But this is too complicated and unreliable.

I wouldn't know why this shouldn't be considered reliable. However, if you want to completely get rid of the file, history and all, no matter what the effect on previous revisions this file was part of, there only is one way to do so and that way is indeed complicated. And rightly so. SVN is a tool with one single goal: never ever to lose any file, even after it was deleted. Forcing it to do otherwise ought to be hard.

I was facing a similar issue, except that I needed to remove multiple files, not just one file, and also we are on Subversion 1.6 which doesn't support the --patern directive.

-- backup current SVN

$ cp -R /svn  /svnSAVE

-- dump repository

$ svnadmin dump /svn/root > svnDump

-- create new dump while excluding the very large file

$ svndumpfilter exclude "/path/file.csv" < svnDump > newSvnDump0
-- {note: should see a message like this}:
--          Dropped 1 node:
--                  '/path/file.csv'

-- create another new dump while excluding another very large file

$ svndumpfilter exclude "/path/anotherFile.csv" < newSvnDump0 > newSvnDump1

-- remove the old svn

$ rm -rf /svn

-- recreate the svn directories

$ mkdir -p /svn/root

-- recreate the SVN

$ svnadmin create /svn/root

-- repopulate the fresh repository with the dump

$ cat newSvnDump1 | svnadmin load /svn/root

-- update the conf files from the saved copy into the new copy...

$ cp /svnSAVE/root/conf/* /svn/root/conf

Now the repository should not contain the 2 large files "file.csv" and "anotherFile.csv"

I agree with McDowell's proposal, but would like to suggest that you consider replacing the large file with a text file that simply contains the hash of the file for the removed entry.

If you have a huge number of, for example, .o files from accidentally checking in a build directory, this may not be appropriate. But if you are removing a bunch of binary artifacts you don't want from a directory that includes a bunch of binary artifacts you DO want, you are at high risk of making an expensive mistake. At a minimum, consider removing them from trunk and most branches, but leaving a feature branch full of placeholder text files with the hash of the original binary. This can at least be enough to figure out what happened later, verify that a stray copy that shouldn't have been deleted is in fact the right file, and put it back under revision control.

And, obviously, back the entire repo up to something read-only, like a couple of M-Discs or something, before you even think about doing any of this stuff.