How do I prune old revisions in Subversion?

Question

How can I prune old revisions from my development subversion repository? I keep a subversion sandbox in which I have lots of test projects, binaries, etc. I'd like to prune the history occasionally.

Answer 1

Here's the official answer:

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.

Found here: http://subversion.tigris.org/faq.html#removal

Answer 2

You can use svndumpfilter.

However it's really not a recommended thing to do. Repositories are supposed to be (mostly) append-only databases. Some amount of data mutation is tolerable thanks to the centralized nature of the database, but it's not supposed to be routine operation.

You should probably use a separate repository for each project instead of one bag repository that you will want to prune from time to time.

Answer 3

You don't really want to prune the history, that way lies madness.

You may want to delete old branches so that they don't appear in your svn browser, but that's just as straightforward as an 'svn rm'. The revisions remain in the version control system.

Answer 4

Jon - we disagree. There are times when it's appropriate to prune "very old" data that we are certain will no longer be needed because it is backed up in some other media. Take for example, a system that tracks versions of configuration files automatically. At some point, it makes sense to say - "We know that we no longer need to have the configuration the way it looked a year ago to be on-line. Having that information in some off-line format is fine, but leaving it on-line in the production systems is not a good thing." That is the perfect example of when it's appropriate to be able to easily archive the very old data, then prune it from the repository. I've found a way around the problem, but I think it is a real hack that I have to effectively re-play history from a certain point in time through all the revisions to create a new repository so I can replace the old one.