Question

我从svndumpfilter得到了奇怪的结果 - 我需要在我们的仓库中删除24个2个特定文件的实例，分散在许多分支中。我正在运行命令，如下所示：

e.g。

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

但是，似乎过滤的转储文件没有按预期删除所有节点，只是删除2.我已经通过在两个转储文件上使用svndumptool diff确认了这一点，并且在重建repo之后，排除的文件仍然存在。

我确定我没有错过任何这些文件的实例，因为我使用svnlook树来查找repo中的所有路径。此外，我已确认在命令和转储文件中前导斜杠是一致的。

有人有什么想法吗？

Answer 1

与此问题相关的

Apache Subversion FAQ entry最近使用一种新方法进行了更新，该方法允许您过滤存储库历史记录。复杂的存储库历史记录过滤可能比使用svndumpfilter方法更方便。

在配置path-based authorization rules 拒绝对存储库历史记录中需要过滤的任何路径的读取权限后，您可以使用svnsync工具复制存储库。

与svndumpfilter不同，svnsync会自动将具有不可读源路径的复制操作转换为正常添加，如果需要过滤涉及复制操作的历史记录，这将非常有用。

Answer 2

您可以尝试执行以下操作，也许它会有所帮助：

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

或者这样：

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

Answer 3

您可以在文件中添加所有前缀，并使用--targets FILE选项而不是单独的exclude | include

Answer 4

我需要删除的文件是历史上的最后一次检查。所以我能够使用svnadmin转储来在转速发生之前转储所有转速。

我需要在rev 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对这个存储库修复非常困难。显然它保留了自己最新版本的内部缓存，当它更新工作副本时，它会从缓存中恢复“坏”修订文件。我想我将不得不再次查看所有内容并制作一份新的工作副本以使其正确。