我从 svndumpfilter 得到了奇怪的结果——我需要在我们的仓库中删除 2 个特定文件的 24 个实例，这些文件分散在许多分支中。我正在运行记录的命令，如下所示：
例如
type dumpfile | svndumpfilter exclude foo1/bar.dat foo2/bar.dat > filtered_dumpfile
但是，过滤后的转储文件似乎没有按预期删除所有节点，而只是删除了 2 个。我已经通过在两个转储文件上使用 svndumptool diff 确认了这一点，并且在重建 repo 后，排除的文件仍然存在。
我确信我没有错过这些文件的任何实例，因为我使用 svnlook 树来定位 repo 中的所有路径。我还确认命令和转储文件中的前导斜杠是一致的。
有人有想法么？
与该问题相关的Apache Subversion 常见问题解答条目最近已使用一种新方法进行了更新，该方法允许您过滤存储库历史记录。复杂的存储库历史过滤可能比使用该svndumpfilter方法更方便。
您可以在配置基于路径的授权规则（拒绝对需要从存储库历史记录中过滤掉的任何路径的读取访问）svnsync之后使用工具复制存储库。
与, 不同svndumpfilter，svnsync将自动将具有不可读源路径的复制操作转换为正常添加，如果需要过滤涉及复制操作的历史记录，这很有用。
您可以尝试如下操作，也许会有所帮助：
type dumpfile | svndumpfilter exclude foo1/bar.dat | svndumpfilter exclude foo2/bar.dat > filtered_dumpfile
或者这样：
svndumpfilter exclude `cat filterlist.txt` < old.dump > new.dump
您可以在文件中添加所有前缀并使用--targets FILE选项而不是单独的排除|包含
我需要删除的文件是历史上的最后一次签入。因此，我能够使用 svnadmin dump 在损坏的转速之前获得所有转速的转储。
这类似于本页中描述的内容：http ://robmayhew.com/delete-parts-of-subversion-history/
我需要摆脱 8195 版的错误签入，所以我运行了如下内容：
svnadmin dump /path/to/current/repo -r0:8194 > svn.dump
svnadmin create /path/to/new/repo
svnadmin load /path/to/new/repo < svn.dump
这行得通，除了我签出的工作副本中仍然有来自 8195 的信息。当我尝试更新时，这会导致错误，因为我的工作副本认为它在服务器中不存在。
我必须进行一次小型签出并在某处签入一个微不足道的更改以使存储库版本恢复到 8195，然后我可以在删除受错误签入影响的文件后清理并更新我的工作副本。这在 linux 中使用 svn 有效。
一位同事在 Windows 中使用 svn，而 Tortoise svn 对这个存储库的修复非常困难。显然，它保留了最新修订的内部缓存，并且当它更新工作副本时，它会从其缓存中恢复“坏”修订文件。我想我将不得不再次检查所有内容并构建一个新的工作副本以使其正确。