要排查svn版本库中占用空间最大的历史文件，核心思路是分析fsfs格式下各修订版本的磁盘占用，通过ls -ls repos_path/db/revs/ | head -20定位体积最大的rev文件，再结合svnlook info -r rev和svnlook changed -r rev识别对应的大文件提交，最后用svnlook cat -r rev path | wc -c或svnadmin dump配合svndumpfilter进行确认与清理。
要排查 SVN 版本库中占用空间最大的历史文件，核心思路是：SVN 服务端存储（如 FSFS 格式）中，每个修订版本的增量数据和已删除但未彻底清理的文件仍保留在历史中，真正占用磁盘的是这些“残留”或“大体积提交”的原始内容。命令行本身不直接提供“按文件大小排序历史”的功能，需结合 svnadmin、svnlook 和 shell 工具协作分析。
定位大体积提交（revision）
SVN 本身不记录单个文件在某次提交中的实际字节变化量，但可借助 svnadmin dump 的统计信息或 svnlook changed + 文件大小估算来识别可疑修订版本。更实用的方法是扫描所有修订，找出新增/替换的大文件：
- 用 svnadmin lstxns REPOS_PATH 检查是否有未完成事务（极少影响空间，但需先排除）
- 运行 svnadmin dump --deltas --quiet REPOS_PATH | grep -E '^Node-path:|^Text-content-length:' 可提取路径与内容长度（需配合脚本解析，适合中小库）
- 更高效方式：使用 svnlook tree -r START:END --full-paths REPOS_PATH 列出各版本变更路径，再对常见大文件类型（如 *.zip, *.tar, *.iso, *.pdf, *.mp4）做关键词过滤
检查特定路径的历史体积贡献
若已怀疑某目录或文件长期膨胀（例如 /trunk/assets/），可用以下组合确认其历史“累计写入量”：
- 执行 svnlook changed -r REV REPOS_PATH | grep '^A\|^M' | awk '{print $2}' 提取新增或修改的路径
- 对每个疑似大文件，用 svnlook cat -r REV REPOS_PATH PATH | wc -c 获取该版本下内容字节数（注意：仅适用于未被删除的当前存在路径；对已删文件需从 dump 中恢复）
- 若文件已被删除但仍在历史中，需用 svnadmin dump --revision REV REPOS_PATH 导出该版本，再用 svndumpfilter include PATH --drop-empty-revs 提取并估算大小
识别未彻底清理的已删大文件
SVN FSFS 在删除文件后不会立即释放磁盘空间，尤其当旧版本仍引用该文件时。真正占用空间的往往是“已删但未被 gc 清理”的旧数据：
- 运行 svnadmin verify REPOS_PATH 确保仓库完整性，避免因损坏导致误判
- 查看 REPOS_PATH/db/revs/ 和 REPOS_PATH/db/revprops/ 目录下各 revision 文件大小，用 ls -lS REPOS_PATH/db/revs/ | head -20 找出体积最大的几个 rev 文件 —— 它们往往对应含大文件的提交
- 结合 svnlook youngest REPOS_PATH 和 svnlook info -r REV REPOS_PATH 查看对应提交的作者、时间、日志，判断是否为误传（如打包文件、构建产物）
清理与后续控制建议
找到问题文件后，单纯 delete 或 revert 并不能回收空间。必须执行深层清理：
- 使用 svndumpfilter exclude PATH --drop-empty-revs filtered.dump 从完整 dump 中剔除目标路径
- 重建仓库：svnadmin create NEW_REPO && svnadmin load NEW_REPO
- 完成后运行 svnadmin pack NEW_REPO（FSFS v6+）压缩 revision 文件，并设置 fsfs.conf 中 pack-size 和 max-pack-size 合理值
- 日常预防：在 pre-commit hook 中限制单次提交文件大小（如拒绝 >10MB 的二进制文件）、禁止特定扩展名、引导团队使用 Git LFS 或独立对象存储管理大资源
