I'm aware of the whole dump|filter|load, obliteration etc. issue. And I agree that normally you don't really have to delete files from history.
However I have what I think is a special case. For the past few years my team was working on a few iOS project, not all of them closely related, but they share some common code, and they are managed on the same svn repo.
Now the problem: the company has decided to transfer further development of one of the projects to a third party. We need to give them that project's code -- including history -- but we don't want to give them the code for the other projects.
How can I do that? For reasons documented by Svndumpsanitizer's author, the dump|filter|load cycle doesn't do the trick; unfortunately, neither does Svndumpsanitizer itself. My current approach is to migrate the repo to git, where you can delete history. But I think that's an overkill.
The official Apache Subversion FAQ entry applies to your case as far as I see ATM.
The new approach that allows you to filter repository history supposedly should help:
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.Also check this answer: https://stackoverflow.com/a/13720677/761095.