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:

  • How to connect to a remote GIT repository?
  • Git repositories on shared hosting with ssh access - multiple users / one ssh account
  • How do I move a local git repo from parent folder to subfolder?
  • Can you have multiple .gitignore files within a single repo?
  • Change Git Repository for pull code
  • Recover code repository in Github?
    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?

  • Git add branch starting from N commits before latest commit
  • Adding Version Control / Numbering (?) to Python Project
  • How to specify the source control plugin on a per-solution basis in Visual Studio?
  • Jenkins: How to push build artifacts back to source control?
  • Converting a local svn repo dump to git
  • How often to comment when committing code?
  • 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.