22

我只是在考虑编写一个 shell 脚本，以一种易于实现的方式（在外部，使用建议的方式，但自动化）来实现 obliterate 功能。

这是我的想法：

在客户端

  1. svn list -R > file-list.
  2. 以 grep 等多种方式过滤文件列表以创建文件“要删除的文件”，类似于一组grep XXX file-list>>files-to-delete.
  3. 使用 scp传输files-to-delete到服务器。

在服务器上

  1. 转储存储库svnadmin dump /path/to/repos > repos-dumpfile，这也可以作为备份保存。
  2. 过滤转储文件，对于“要删除的文件”中的每个单词，执行以下操作：cat repos-dumpfile | svndumpfilter exclude $file > new-dumpfile
  3. 创建一个新存储库并将新文件加载到其中svnadmin create new-name; svnadmin load new-name < new-dumpfile

这行得通吗？怎么会失败？还有其他想法吗？

4

4 回答 4

7

是的，该脚本会起作用。但通常你不会删除那么多文件。通常只有在您意外提交机密信息时才需要删除。

您确定要对这么多文件使用 obliterate 吗？

于 2009-02-18T14:23:39.370 回答
6

我认为这cat new-dumpfile | svndumpfilter exclude $file > new-dumpfile是一个危险的例子。new-dumpfile 不会被完全处理，它的内容可能会丢失，不是吗？

从下面的评论中：new-dumpfile 肯定会丢失，因为即使在启动命令之前，shell 也会破坏它（截断到零长度）。

于 2009-03-19T20:29:21.140 回答
4

我有一个类似但稍微复杂一点的要求。在过去的数百次修订中，一些非常大 (>1GB) 的示例数据文件被提交到存储库。然后它们被移动并最终从 HEAD 中删除。然而，它们仍处于修订历史中，使存储库变得非常庞大。我无法使用svn list -R，因为文件不再出现在工作副本中。

但是，svn list可以给出一个修订参数。我不确定大文件是什么时候签入的，但我知道那是在 2000 年修订版之后的某个时间。我还有一个文件名列表。所以我使用了一个简单的循环和 uniq 来生成我的files-to-delete：

cd $working_copy
for rev in {2000..2437}; do
    svn ls -R -r$rev | grep -f ~/tmp/big-file-names >> ~/tmp/file-paths;
done
cat ~/tmp/file-paths | sort | uniq > ~/tmp/files-to-delete
cd ~/tmp
# You should inspect "files-to-delete" to see if it looks reasonable!
cat dumpfile | svndumpfilter exclude `cat files-to-delete` > dumpfile.new
于 2010-12-16T01:15:35.667 回答
0

不同版本中具有相同路径的文件呢？例如，如果您提交/trunk/foo，然后将其重命名为/trunk/bar，然后提交/trunk/foo您想要删除的其他内容。你不想失去现在的历史/trunk/bar。也许svndumpfilter支持挂钩修订？

于 2010-01-25T12:37:43.003 回答