要看SVN服务器的文件夹大小，最直接的办法是拉取工作副本后用本地文件系统的du命令统计，但如果你只想在SVN命令本身里找结果，svn list不递归汇总目录体积，服务端则用svnlook和操作系统的du来查仓库物理占用。这个需求很典型，尤其是项目仓库越堆越大、服务器空间告急的时候,下面我把几种常见场景和操作方式拆开讲清楚。
先搞清楚你要看的是“哪个”文件夹大小
SVN的资料库和普通磁盘目录不一样，服务器上的仓库（Repository）内部有一套私有格式，直接ls只会看到一堆db、conf之类的内部目录，看不到正常的项目文件树，所谓“服务器的文件夹大小”,通常指下面三种情况之一：
- 仓库内某个路径对应全部文件的逻辑体积,也就是用户检出后看到的文件累加总大小。
- 仓库在服务器磁盘上实际占用的物理空间，包含历史版本、日志、临时数据。
- 工作副本本地目录占用的空间，包含隐藏的
.svn元数据。
很多人混淆的是第一种和第三种，你要看服务器上某个版本目录有多大，实际上必须借助SVN的协议或命令,本地目录大小并不等于服务器文件夹大小。
用svn命令查看服务器目录大小的常见做法
严格说，SVN原生命令没有“给我一个文件夹递归总大小”这样的单条指令。svn list -v可以显示每个文件的字节大小，但它只列当前目录的项目，不带-R参数就不递归，带了-R也只是按路径逐条列出来,不会给你汇总结果。
实操时可以这样试：
- 在本地随便找个目录，执行
svn list -v -R 仓库URL/某个文件夹。 - 输出结果里每行包含版本号、作者、字节数、路径,把字节数累加起来就能算出目标文件夹的当前版本总大小。
- 如果只想看一级目录下几个大文件，可以直接
svn list -v 仓库URL/文件夹。
这个办法能看，但体验不好路径一大，输出非常长，手动算不现实，多数情况下大家会选择把输出重定向到文件，再写一行awk或python去累加，行业共识认为：用svn list算目录大小不是正规做法，临时应急可以，长期监控不推荐。
还有一种思路是直接看SVN的svnlook命令，这是运行在服务器端的工具，不需要走网络协议，在服务器上定位仓库目录后执行
svnlook tree 仓库路径/ --full-paths，能看到完整的目录树，但同样只给结构,不给累计大小。
业内专家指出，服务端真正能反映仓库物理体积的命令只有svnadmin info配合文件系统工具。
把服务器文件夹拉下来统计，最实用的场景方案
如果你有仓库的访问权限，最朴素也最准确的方法是checkout或export下来再统计。
操作路径如下：
- 在服务器或者本地执行
svn export 仓库URL/目标文件夹 --force /本地临时目录。 - 用
du -sh /本地临时目录查看总大小。 - 用
du -sh /本地临时目录/查看每个子目录占用，按大到小排序用du -sh /本地临时目录/ | sort -rh。
这一步最接近“服务器文件夹大小”的真实含义，因为export拿到的就是当前版本的所有文件，不包含版本信息，也不包含其他分支的历史，如果你只想看线上某个版本目录,直接用SVN修订号指过去：
svn export 仓库URL/目标文件夹@HEAD /tmp/size_check --force对于现代服务器来讲，几十GB的仓库执行export会消耗磁盘IO和网络带宽，需要谨慎一些，替代方案是只拉取目标目录的版本信息，用svn log配合svn diff去估算增量，但准确性一般,不建议求精确值的时候用。
服务器端直接查物理占用，定位仓库体积
如果你作为管理员可以登录SVN服务器，那比svn list和export都省事常用，先在服务器上找到仓库的存储位置,然后用系统命令查起来：
find / -name "format" 2>/dev/nullSVN仓库的根目录下有一个format文件，找到它就能定位仓库根,然后执行：
du -sh /path/to/repos
du -sh /path/to/repos/db仓库物理大小里，db目录是重头戏，包含所有版本的文件。多数情况下，仓库物理体积会明显大于检出的目录大小，因为SVN会保存每一次修改的副本，要区分具体是哪一个路径在消耗仓库空间，只能靠svn log逐个目录看变更频率，或者用svnadmin写脚本遍历。
这里有一个成本对比表格：
| 方法 | 适用角色 | 能否看“服务器文件夹总大小” | 依赖条件 | 资源消耗 |
|---|---|---|---|---|
svn list -v -R
|
普通用户 | 需手动累计，不算直接结果 | 网络权限 | 低 |
svn export + du |
普通用户/管理员 | 能，直观准确 | 磁盘空间，网络带宽 | 取决于目录大小 |
svnlook tree |
服务器管理员 | 不能，只看结构 | 服务器shell | 低 |
du -sh /仓库路径 |
服务器管理员 | 能，但看的是物理仓库不是某个逻辑文件夹 | 服务器shell | 低 |
第三方脚本svn-du |
普通用户/管理员 | 能，按路径汇总 | Python/Perl及SVN命令 | 中等 |
第三方工具如svn-du是开源世界里常用的办法，它本质上也是遍历svn list --xml输出后按路径累加，使用前需要确认服务器允许SVN的--xml输出,一般主流SVN版本都支持。
不同布局下的拆分统计思路
大型项目通常会把SVN服务器规划成多个仓库，而不是一个大仓库套所有目录,只看单个文件夹时先想清楚仓库布局：
- 每个项目独立仓库：直接对目标仓库执行
svn list -v -R或du,范围明确。 - 单仓库多项目：需要先明确“文件夹”是指多仓库里的一级目录，如果是，建议用
svn export到本地后du -sh逐级看；如果只是判断哪个子目录占比大，可以先du -sh远程拉下来的临时目录。 - 多仓库共用一套认证：最好把URL路径作为唯一标准,不要凭文件名猜服务器路径。
SVN的服务器端文件夹和本地工作副本不同步，是正常现象，如果你在本地右键看某个.svn覆盖的目录属性，会看到“工作副本大小”，那个数值不反映服务器仓库的存储压力。工作副本里的.svn目录保存了本地修改记录和原件副本，某些情况下它的体积甚至占到整个工作目录的20%-40%,具体比例取决于文件变更频率和目录深度。
服务器空间不够时反过来排查
想看服务器文件夹大小，通常是因为磁盘告警了,这时要反过来操作。
优先查/var/svn或/data/svn这类默认路径下的db目录，用du -h --max-depth=2一层层排出来，找到消耗大的仓库后问一下对应项目负责人,确认是否有不再使用的历史数据。
SVN本身没有内置“瘦身”命令，删除旧版本的标准操作是
svnadmin dump加svnadmin load重建，即先导出需要保留的最新中国版本，再导入到一个新仓库里，然后废弃原仓库,步骤可以概括为：
svnadmin dump 原仓库 -r 起始版本:最新版本 > dumpfile。- 创建新仓库
svnadmin create 新仓库路径。 svnadmin load 新仓库路径 < dumpfile。- 停掉原仓库访问,切换URL指向到新仓库。
如果你在考虑svn怎么清理服务器空间，上面这个步骤是业内默认的一整套方案，它能够把历史中的超大中间版本去掉，腾出磁盘，但要注意dump文件本身也需要额外磁盘空间,预估的时候留好余量。
总结一条主线的执行顺序
说到底，svn怎么看服务器的文件夹大小，标准思路是从外到内、从逻辑到物理：
- 想知道业务层面目录大小，用
svn export加本地du -sh。 - 想知道仓库整体物理占用，登录服务器用
du直接扫。 - 想在不出网的情况下批量统计，用
svn list --xml配合脚本处理。
不同方法的精确度差异不大，只是查起来的方便程度和使用权限不同。核对哪个目录最大之后，及时清理工作副本里的多余文件，或者和项目方确认历史版本是否可裁减，才是真正解决服务器空间问题的出路。
Q&A：svn查看服务器文件夹大小的常见疑问
svn怎么查看服务器的单个目录大小？
可以用svn list -v -R 仓库URL/目录列出该目录下所有文件的字节数，再自己汇总，批量统计建议配合脚本，输出XML格式后用程序解析，实践中最常用的是临时svn export后用du -sh做最终统计。
svn服务器怎么看哪个仓库占空间比较多？
登录SVN服务器，用find / -name "format"定位仓库根目录，然后执行du -sh逐一查看每个仓库路径即可快速比较，仓库的物理体积主要存储在db目录里，它属于SVN服务器端文件布局,不通过SVN命令直接暴露给用户。
svn服务端本身有没有类似du的命令？
没有专门的“svn du”原生参数，svnlook只提供树形结构和属性查看，不做体积累加，通用做法是利用操作系统的du和find来查看服务器上的仓库目录，需要按路径统计时就依赖第三方脚本，比如svn-du这类基于svn list --xml输出的开源工具。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/701478.html
