Problems with svndumpfilter, not excluding the path

Question

I get strange results from svndumpfilter - I need to destroy 24 instances of 2 specific files in our repo, scattered among many branches. I run the command as described like this:

eg.

type dumpfile | svndumpfilter exclude foo1/bar.dat foo2/bar.dat > filtered_dumpfile 

However, it seems that the filtered dump file does not delete all nodes as expected, but only deletes 2. I confirmed this using svndumptool diff for the two dump files, and after restoring the repo all the files that remained remained.

I am sure that I did not miss a single instance of these files, since I used the svnlook tree to search all paths in the repo. I also confirmed that leading slashes are consistent in the command and in the dump file.

Does anyone have any ideas?

Answer 1

The entry in the Apache Subversion FAQ , which is related to the question, has recently been updated with a new approach that allows you to filter the repository history. Comprehensive filtering of the storage history can be a little more convenient with it than with the svndumpfilter approach.

You can replicate the repository using the svnsync tool after setting up path-based authorization rules that deny read access to any paths that need to be filtered from the repository history.

Unlike svndumpfilter , svnsync automatically converts copy operations with an unreadable source path to regular add-ons, which is useful if you need to filter the history associated with copy operations.

Answer 2

You can try the following, maybe this will help:

 type dumpfile | svndumpfilter exclude foo1/bar.dat | svndumpfilter exclude foo2/bar.dat > filtered_dumpfile 

or as follows:

 svndumpfilter exclude `cat filterlist.txt` < old.dump > new.dump 

Answer 3

You can add all the prefixes to the file and use the --targets FILE option instead of a separate exclude | include

Answer 4

My files that I needed to destroy were the last check in history. Therefore, I was able to use the svnadmin dump to get a dump of all revolutions before a broken revolution.

This is similar to what is described on this page: http://robmayhew.com/delete-parts-of-subversion-history/

I needed to get rid of error checking in rev 8195, so I ran something like this:

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

This worked, except that my verified working copy still had information from 8195 in it. This caused an error while trying to upgrade, as the version of my working copy believed that it did not exist on the server.

I needed to make a mini-check and check somewhere a trivial change to get the repository version to 8195, after which I can clear and then update the working copy after deleting the files affected by the bad check. This worked using svn on linux.

An employee uses svn in windows, and Tortoise svn really had a problem with this repository fix. Apparently, it saves its own internal cache of the latest version, and when it updates the working copy, it restores the “bad” revision files from its cache. I think I will need to check everything and create a new working copy so that everything is correct.