最近一个版本管理服务器发生了硬盘空间不够的问题。调查结果是其中一个版本库居然有47G，占据了大部分的服务器硬盘空间。经过跟使用的公司协商，决定采用删除版本库早期履历的方式缩减版本库尺寸。
具体作业过程如下：

准备工作

停止apache服务器，修改版本库目录路权限为root的方式，阻止所有的用户使用该版本库。重启apache，这样可保证其他版本库的用户继续使用。

备份原有版本库。

版本库全备份可以采用svnadmin dump和svnadmin hotcopy两种方法。在整个过程中两种方法都会用到。首先作为版本库全备份，以防将来出现作业错误时可以立刻恢复原有版本库的操作，建议使用svnadmin hotcopy。一方面这样的备份速度比较快，另一方面备份的结果就是一个可以立刻使用的版本库，在需要恢复的时候直接拷贝回去就行了。具体命令如下：
svnadmin hotcopy --clean-logs /path/to/repo ./hotcopy >hotcopy.log 2>hotcopy_err.log &
备份的结果就是一个目录，尺寸基本和原版本库相同，47G。

dump版本库需要保留的版本。

通过svnlook youngest /path/to/repo命令可以看到版本库最后的版本是多少。我要作业的版本库是14079。经过跟对方公司协商，决定保留10000到14079之间的版本。因此需要从版本库把10000以后的版本dump出来。具体命令如下
svnadmin dump /path/to/repo -r 10000:14079 > repo_dump_10000-14079.dmp 2>repo_dump_10000-14079.log &
dump出来的文件大约34G。
查看一下日志文件，确定所需要的版本都被正确的dump下来了。

重建版本库

rm -rf /path/to/repo
svnadmin create /path/to/repo
注意这里面没有使用 --fs-type bdb参数，因此创建出来的版本库是FSFS后端的。后面还会继续解释为什么这么做。

重新导入新版本

svnadmin load /path/to/repo < repo_dump_10000-14079.dmp > repo_load.log 2>repo_load_err.log &
检查一下日志文件，看看load是否成功。用svnlook命令看看load以后版本库的最新版本。

修改版本库权限

chown -R apache:apache /path/to/repo

到此为止版本库的历史版本删除工作就结束了。需要注意的是，新建出来的版本库的最新版本应该是4080。另外，经过观察，新创建出来的版本尺寸只有2.7G。这个结果曾经一度让我怀疑load没有成功。但是事实上确实如此。需要说明的是，原来那个占了47G的版本库就是BDB格式的。我又试着创建了一个BDB后端的版本库，用同样的方式把dump文件导进去，结果版本库的尺寸接近30G。而且导入的速度来看也明显比向FSFS后端版本库导入要慢很多。大概多了一个多小时的时间。可见BDB后端和FSFS后端版本库在某种情况下的尺寸差距惊人的大。手册是虽然也说了FSFS会比BDB小一些，但是绝对没想到会小那么多。subversion现在主推FSFS格式是有道理的。但是我总觉得毕竟BDB历史更悠久一些，也更稳定一些。所以在今后硬盘空间不紧张的前提下，我还是倾向于使用BDB后端格式。