我正在使用一个超过3年的SVN存储库，包含超过6,100次提交，并且大小超过1.5 GB。我想在将SVN存储库移动到新的服务器之前，减少SVN存储库的大小（我不是在谈论完整SVN导出的大小 - 我的意思是存储在服务器上的完整存储库）。如何识别并删除SVN存储库中的大型二进制提交？
当前的存储库包含的源代码，我们所有的软件项目，但它也包含了没有意义的比较大的二进制文件，如：
许多这些大文件自从被添加以来一直被'SVN删除'，从而产生了识别最大罪犯的进一步问题。
我想要么：
其中任何一种可能吗？
您将不得不使用svnadmin dump来获取当前存储库的转储文件，并可能使用svndumpfilter来处理转储文件。只要你很小心，你也可以手动修改转储文件。
这可能不会是一件快速简单的工作，但它可以完成。我做了类似的事情，只做了一个更小的存储库。我有一个回购约150个修订约600MB。
从您当前的存储库中进行转储，进行必要的更改并尝试将修改后的转储文件加载到新存储库中。然后检查新的存储库以确保一切仍然有意义（历史记录仍然正确，路径中没有奇怪的更改，...）。
这不就是一个不同的问题，有一个额外的步骤？即您需要找到您认为是大型和二进制文件，然后检查它们是否确实由SVN管理，或者本地构建（或从并行资产系统导入，如果已经就位）。
因此，只需找到这些文件，然后对它们做svn info以查明它们是否是存储库的一部分。
SVN信息库已经存在了3年多了，在此期间，我所指的大部分文件都被'SVN删除'了。还有一个大的二进制文件在开发过程中遇到了问题（比如大型的PSDs），之后这些文件已经固化并且不再改变 - 所以在这种文件的不同提交中，增量可能会有20MB（我'米不知道如何找到）。 – InvertedAcceleration 2010-02-01 13:20:09
我已根据您的答案大幅更新了问题，以确保我能正确沟通情况。我希望这有助于澄清一些观点。感谢您的初步答复。 – InvertedAcceleration 2010-02-01 13:46:26
如果您使用“SVN删除”从存储库中删除了文件，您并未真正删除这些文件。这将是SVN的美丽。一旦文件被添加到存储库中，它就会永远存在（除非使用dump &加载）。在“删除”这些文件时，您实际上会创建一个标记为删除的新修订版，但这些文件在以前的修订版中仍然存在。
我已经做了一些转储&负载，但对一个更大的存储库。大约60,000（!!!）版本。这需要时间，但最后，仔细加载后，库又重新建成。
您唯一的方法是列出文件添加，修改和删除的修订版本。然后转储它们之间的修订版，并按正确的顺序加载它们。 BE AWARE，没有犯错的余地。如果你犯了一个错误，你将不得不重新开始。转储&从一开始就加载。
我的建议，如果大文件是这样的问题，考虑创建一个没有历史的新鲜的存储库。保留旧的历史比较，并从新鲜开始工作。
祝你好运。
只是一个小小的想法，你说仓库的当前状态（当前HEAD）是好的，即大的二进制文件在过去被svn删除了。因此，您的问题纯粹是存储库的大小？
我知道你说过你想保留所有的提交历史，但作为选项，你可以做两个转储，一个用于整个修订历史，另一个用于当前的HEAD修订。
如果你把完整的转储放到DVD上，例如，如果你需要它的话，你可以得到可用的数据，但是你可以删除整个存储库，然后svn加载修订转储，留下一个小的干净存储库。
，也可以从一个特定的修订开始抛售，而不仅仅是头部，因此，例如你可以保持过去3个月的修订和转储一切旧的到一个DVD ....
阿瑟赛德是正确的约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$"
如果你只需要找到有问题的承诺和您可以访问托管库的服务器：寻找在仓库中的DB /转速子目录大文件（假设它使用FSFS格式）。
在阐述阿瑟赛德的答案，这里是专门为我工作：
svnadmin create new-repo
svnadmin dump old-repo | svndumpfilter exclude --pattern '*.exe' '*.jpg' '*.png' | svnadmin load new-repo
您可能能够通过将它们添加到svndumpfilter命令来排除Obj和Bin目录 - 我没有尝试。
此外，Subversion的fsfs-stats程序（Subversion 1.8中的新功能，替换为1.9中的svnfsfs stats）对于量化填充存储库的文件类型和特定文件可能很有用。
这可能是以后比较有用的资料库：当你后悔做这个
colordiff -u <(svn log -v file:///.../old-repo) <(svn log -v file:///.../new-repo)
这一天会来的。但是，如果你继续前进，其他人对“svnadmin dump”是正确的。 – 2010-02-02 01:54:27
为什么我会后悔（诚实的问题 - 而不是挑战！）？我只是想摆脱SVN中的内容，这些内容可以存储在其他地方（我会这样做），或者根本不需要存储。据我现在看到，唯一的遗憾是，如果svnadmin转储和svndumpfilter损坏存储库历史记录，并且只有在许多提交完成后才能识别它。你是否认为历史腐败可能？ – InvertedAcceleration 2010-02-02 09:45:22