4

I am getting strange results from svndumpfilter - I need to obliterate 24 instances of 2 specific files in our repo, scattered amongst many branches. I am running the command as documented like so:

e.g.

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

However, it seems the filtered dump file is not removing all of the nodes as expected but only removing 2. I have confirmed this by using svndumptool diff on the two dump files and after rebuilding the repo the excluded files are still present.

I'm sure I haven't missed any instances of those files as I have used svnlook tree to locate all paths in the repo. Also I have confirmed that leading slashes are consistent in the command and in the dump file.

Anyone have any ideas?

bahrep
  • 29,961
  • 12
  • 103
  • 150
RyanG
  • 3,973
  • 25
  • 19
  • I am having the same problem. Following instructions in http://svnbook.red-bean.com/en/1.7/svn.ref.svndumpfilter.commands.c.exclude.html, this should be removing four folders from my repo, but they are still there. I thought it might be a quote problem since some have spaces in files names, and I also checked the leading slashes. – Mnebuerquo May 29 '14 at 02:14

4 Answers4

2

Apache Subversion FAQ entry which is related to the question has been recently updated with a new approach that allows you to filter repository history. Complex repository history filtration may be a bit more convenient with it than with the svndumpfilter approach.

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

Unlike svndumpfilter, svnsync will automatically translate copy operations with an unreadable source path into normal additions, which is useful if history involving copy operations needs to be filtered.

bahrep
  • 29,961
  • 12
  • 103
  • 150
0

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

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
0

My files I needed to obliterate were the last checkin in the history. So I was able to use svnadmin dump to get a dump of all revs prior to the broken rev.

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

I needed to get rid of a mistake checkin at 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 my checked out working copy still had info from 8195 in it. This caused an error when I would try to update, since the version my working copy thought it had didn't exist in the server.

I had to do a mini-checkout and check in a trivial change somewhere to get the repository version back up to 8195, then I could cleanup then update my working copy after deleting the files affected by the bad checkin. This worked using svn in linux.

A co-worker uses svn in windows, and Tortoise svn has been really difficult about this repository fix. Apparently it keeps its own internal cache of the latest revision, and when it updates the working copy it restores the "bad" revision files from its cache. I think I'm going to have to check out everything again and build a fresh working copy to get it right.

Mnebuerquo
  • 5,759
  • 5
  • 45
  • 52
0

You can try to do as follows, maybe it will help:

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

or this way:

svndumpfilter exclude `cat filterlist.txt` < old.dump > new.dump
altern
  • 5,829
  • 5
  • 44
  • 72