VisualSVN 提交 commit 失败，Repositories变大，SVN数据库紧缩的问题 ；SVN备份的问题。

    某人上提交Subversion一个非常非常大的文件（离线地图），上传时间非常长，上传中途被强制的终止掉了。【根本没有必要上传这个文件。Subversion不是FTP， 不宜用来存放不需要版本控制的文件(例如 二进制文件)。SVN是用来文本格式的源代码文件的版本控制和管理。】

    看SVN日志, 没有这次上传的日志，SVN中也没有上传的文件。 但当进行文件复制备份SVN时（这种方法不好），发现数据库的体积增加了许多，备份时间大幅度增加了。

    紧缩Subversion数据库的方法简述就是：svnadmin dump 导出全部SVN库， 再 svnadmin load 导入。

用dump导出这个Repositories，再load 导入一个新建的 Repositories中，删除原来的Repositories，改名新创建的 Repositories 成原来的名字，整个数据库的大小， 缩小了许多，似乎数据库被紧缩了(当然 SVN 原本就有一个pack命令, 但没敢在生产库上试用)。但是一个代价是，原本仓库的权限设置数据,全部丢失了， 需要对新仓库重新设置用户/组的访问权限。

用到的命令:

导出数据:

svnadmin dump E:\Repositories\DS6000 > DS6000.dump

如果需要过滤掉无用的数据:

例如：在导出数据  DS6000 .dump 中， 删除Software\Dispatcher目录及其之下的所有文件和目录 的例子
svndumpfilter exclude Software\Dispatcher  <DS6000.dump> filtered-DS6000.dump

导入数据:

svnadmin load  E:\Repositories\DS6000new <  DS6000.dump

或者
svnadmin load  E:\Repositories\DS6000new < filtered-DS6000.dump

删除原来的Repositories和改名新的Repositories成原来的名字, 这些操作可以在VisualSVN中完成, 也可以在操作系统中完成

重新设置用户/组的访问权限.

另外，看到一则Blog说，svnadmin hotcopy 也可以紧缩 SVN 数据库。cf：https://www.jianshu.com/p/295b423d50ad

经过实际的测试， svnadmin hotcopy 的确可以减少文件数和目录数量。（文件数量甚至大幅度的减少了。）减少版本库所在目录的大小。

结论： dump&load 和 svnadmin hotcopy 两种方法，均可以紧致 Subversion 的数据库。

    Subversion备份问题： 直接备份Pepositories文件，应该是最不好的方法，需要停止SVN服务。Dump&Load备份的方法，无法备份SVN的权限设置，hook脚本等数据。（但可以选择备份数据库在一部分数据）

备份SVN 的最好方法，是用 svnadmin hotcopy 备份的方法，第一次要全部备份（耗时巨长），然后用 svnadmin hotcopy --incremental 选项，每次增量备份，速度飞快。svnadmin hotcopy 这种备份方法无法备份  VisualSVN 的配置数据（包括：用户，分组&用户权限 ,这3个文件还是手工备份一下吧！）