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:

  • concept of bare shared repository in git
  • How do I protect my Python codebase so that guests can't see certain modules but so it still works?
  • Move an SVN respository when the server is dead
  • How do I fix missing git remote details?
  • Git: I want to refactor my codebase, and create new files structures and move things around. Will my git history be maintained?
  • Heroku 'Permission denied (publickey) fatal: Could not read from remote repository' woes
    1. Dump all repo with the help of svnadmin utility.
    2. Filter dumped file with grep. Grep should use filename and write 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?

  • How to fully delete Subclipse plugin?
  • TFS query (in Visual Studio) to get all check-ins
  • How can I author changes that are not prone to merge conflicts?
  • git merge vs rebase using git svn
  • How do you get git repos name in some git repository?
  • SharpSVN get post-commit-hook with 'SvnLookClient'
  • 4 Solutions collect form web for “Delete file with all history from svn repository”

    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.

    Git Baby is a git and github fan, let's start git clone.