What's the best way to clean up a Subversion repository?

I have a growing repository containing a dozen or so projects that I maintain using TortoiseSVN (as I am completely new to this and don’t know the ins and outs yet). The space I have to hold the repository is limited so I want to back it up, then remove some of the older versions. For example, if a project is at version 50, I want to keep only 50,49,48.

  • Best general SVN Ignore Pattern?
  • svn:ignore not ignoring xcuserdata
  • Are code freezes irrelevant with Git?
  • Can I merge two Microsoft Word documents reliably with Subversion?
  • Remove specific files from revision history
  • SVN commit error: “'.' is not a working copy”
  • Version-controlled extension configuration in Mercurial
  • Number of commits in a git repository
  • Is it possible to set git up to have default fetch/push locations that are different, and if so, how?
  • Error with Git SVN clone
  • How well does git scale in terms of users/code base size?
  • Recover files from old Subversion backup
  • 3 Solutions collect form web for “What's the best way to clean up a Subversion repository?”

    Removing old revisions kind of defeats the point of version control, but you can just dump out the revisions you want to keep, then put them into a new repo, and delete the old one.

    svnadmin dump /path/to/current/repo -r48:50 > svn.dump
    svnadmin create /path/to/new/repo
    svnadmin load /path/to/new/repo < svn.dump

    Or use svndumpfilter to include/exclude the particular bits you want, etc. There also some info in the svn FAQs about removal that you may find useful.

    Can I delete older revisions or repositories to free up storage space?

    The short answer is no. The way Subversion and CVS work is that they keep an entire history of changes, including deleted files, binary files, etc. Each revision is dependent on the last revision, so you can’t just chop out a revision somewhere in the middle or you corrupt your repository. There are 2 things you can do if you are running out of space: 1) Delete your module, and re-create it using just the HEAD revision, which will clear out all old revisions (but you will lose your commit history). 2) The better option- upgrade to a higher plan :-). This is less of an issue with Git since it has a much less server side storage requirement.

    How do I completely remove a file from the repository’s history?

    There are special cases where you might want to destroy all evidence of a file or commit. (Perhaps somebody accidentally committed a confidential document.) This isn’t so easy, because Subversion is deliberately designed to never lose information. Revisions are immutable trees which build upon one another. Removing a revision from history would cause a domino effect, creating chaos in all subsequent revisions and possibly invalidating all working copies.

    The project has plans, however, to someday implement an svnadmin obliterate command which would accomplish the task of permanently deleting information. (See issue 516.)

    In the meantime, your only recourse is to svnadmin dump your repository, then pipe the dumpfile through svndumpfilter (excluding the bad path) into an svnadmin load command. See chapter 5 of the Subversion book for details about this.

    quoted from:



    There’s no way to “snip” a repository at a particular revision in the manner you describe. What you could do is svn export the whole repository at the desired revision, then import it into a new repository, then replay the commits from the revisions after that from your log file into the new repository. This is not trivial.

    Alternatively, if you just want to exclude some cluttered paths from your repository, and you have direct access to the file system where the repository is residing, you can use a combination of svnadmin and svndumpfilter to select the paths you want and prune all others.

    Note that what you’re describing is more or less against the point of Subversion: it’s supposed to keep everything. If you frequently have trouble with this, consider establishing better checkin practices. Or consider using Git, which makes this sort of experimentation virtually free.

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