我正在使用一个超过3年的SVN存储库，包含超过6,100个提交，大小超过1.5 GB。我想减少SVN存储库的大小（我不是在谈论完整SVN导出的大小 - 我指的是服务器上存在的完整存储库），然后再将其移动到新服务器。
当前存储库包含我们所有软件项目的源代码，但它也包含相对较大的二进制文件，如下所示：
这些大型文件自添加以来一直被'SVN删除'，这进一步造成了识别最大罪犯的问题。
我想要：
这些都可能吗？
答案 0 :(得分：8)
其他方面关于svnadmin dump等是对的。像这样的东西会让你粗略地指向为你的回购添加大量数据的修订，并且是svndumpfilter的候选者：
for r in `svn log -q | grep ^r | cut -d ' ' -f 1 | tr -d r`; do
echo "revision $r is " `svn diff -c $r | wc -c` " bytes";
done
您也可以尝试这样的方法来查找添加了具有特定扩展名的文件的修订版（此处为.jpg）：
svn log -vq | egrep "^r|\.jpg$" | grep -B 1 "\.jpg$"
答案 1 :(得分：4)
您必须使用svnadmin dump来获取当前存储库的转储文件，并可能使用svndumpfilter来处理转储文件。只要您小心，也可以手动修改转储文件。
这可能不会是一项快速而简单的工作，但可以做到。我做了类似的事情，只做了一个小得多的存储库。我有一个大约150个修订版的回购，大约需要600MB。
从当前存储库进行转储，进行必要的更改并尝试在新存储库中加载已修改的转储文件。然后检查新的存储库以确保一切仍然有意义（历史记录仍然正确，路径中没有奇怪的变化，......）。
答案 2 :(得分：1)
如果使用“SVN删除”从存储库中删除了文件，则实际上并未删除文件。这将是SVN的美丽。将文件添加到存储库后，它将永远存在（除非使用dump＆amp; load）。在“删除”文件时，您实际上创建了一个标记删除的新修订版，但文件在以前的修订版中仍然存在。
我做了一些转储＆amp;加载，但到更大的存储库。大约6万（!!!）修订。这需要时间，但最后，在小心加载后，再次构建存储库。
您唯一的方法是列出添加，修改和删除文件的修订版。然后转储它们之间的修订，并按正确的顺序加载它们。请注意，没有错误的余地。如果你犯了错误，你将不得不重新开始。转储＆amp;从一开始就加载。
我的建议是，如果大文件存在这样的问题，请考虑创建一个没有历史记录的新鲜存储库。保留旧的历史比较，并开始新的工作。
祝你好运。
答案 3 :(得分：1)
如果您只需要查找违规提交和，您就可以访问托管存储库的服务器：在存储库的db / revs子目录中查找大文件（假设它使用fsfs格式）。
答案 4 :(得分：0)
这不是一个不同的问题，还有一个额外的步骤吗？即您需要找到您认为是大型和二进制的文件，然后检查它们是否确实由SVN管理或者是否已在本地构建（或者从并行资产系统导入，如果它已经到位）。
所以，只需查找文件，然后对它们svn info进行检查，看看它们是否属于存储库。
答案 5 :(得分：0)
只是一个小小的想法，你说存储库的当前状态（当前的HEAD）是好的，即过去已经删除了大的二进制文件svn。因此，您的问题纯粹是存储库的大小？
我知道你说你想保留所有的提交历史记录，但作为一个选项，你可以做两个转储，一个用于整个修订历史，一个用于当前的HEAD修订。
如果您将完整转储放到DVD上，例如，如果您需要数据，则可以获得数据，但是您可以删除整个存储库并svn加载修订转储，留下一个小的干净存储库。
也可以从特定的修订版本开始转储，而不仅仅是头部转储，例如，您可以保留最近3个月的修订版本并将旧版本的所有文件转储到DVD上....
答案 6 :(得分：0)
阐述了对于其他人的回答，这是我特别有用的东西：
svnadmin create new-repo
svnadmin dump old-repo | svndumpfilter exclude --pattern '*.exe' '*.jpg' '*.png' | svnadmin load new-repo
您可以通过将Obj和Bin目录添加到svndumpfilter命令来排除它们 - 我没有尝试过。
此外，Subversion的fsfs-stats程序（Subversion 1.8中的新程序，由1.9 svnfsfs stats替换）可能对量化填充存储库的文件类型和特定文件很有用。
这可能对以后比较存储库很有用：
colordiff -u <(svn log -v file:///.../old-repo ) <(svn log -v file:///.../new-repo)