今天有一位用户发信给 Release Engineering Team，要求在发行版中提供源代码的 svn checkout 工作副本，以便直接使用。我觉得这是个好主意，因为这样可以用更便宜的 FTP 流量来代替 svn 流量；不过，由于 re@ 内部有人担心这样会让光盘映像继续膨胀，因此我做了些测试来评估这样做的影响。

总共做了 7 个试验。

1. 直接用 tar 打包 src/ 目录，包括工作副本和 .svn 元数据；
2. 首先用 find -ls 列出文件，然后按文件尺寸排序，最后按这个列出的顺序打包： find src -ls | sort -nk7,11 | awk ‘{ print $11; }’ | tar cT - -nf - > src.tar；
3. 还是按尺寸排序，但只打包 .svn 本地元数据；
4. 还是按尺寸排序，但只打包工作副本；
5. 将文件名翻转，排序，然后按这个列出的顺序打包：find src | rev | sort | rev | tar cvT - -nf - > src.tar
6. 直接用 tar 打包 src/ 目录的工作副本，去掉 .svn 元数据
7. 直接用 tar 打包 src/ 目录中的 .svn 元数据，去掉工作副本

以上 tar 包均使用 xz -9e 压缩，得到的文件尺寸如下：

1. 203,578,412
2. 109,820,392
3. 103,532,188
4.  97,677,384
5.  95,410,832
6.  92,918,392
7. 111,353,028

以上并不是非常严谨的测试，不过我们还是可以得到一些初步结论：

FreeBSD 的代码本身的模块组织对压缩的帮助要比文件名类似的情况对压缩的帮助来的大（#6 vs #5 和 #4）。同一模块中的代码的相关信息更多，由于它们在 tar 中的位置比较接近，因此对压缩的帮助很大。

subversion 的 .svn 目录结构对压缩是非常不友好的（将不相关的文件硬塞在一起）。 #1 的尺寸几乎等于 #6+#7 的尺寸（而事实上，#6和#7的内容几乎是完全相同的）。

通过按尺寸排序，可以帮助系统将内容类似的文件排列到一起：#1 和 #2 中的内容、tar文件尺寸完全一样，但 #2 省了 47% 的空间（压缩后）。

增加 .svn 目录，按目前较好的方式去压缩，要比现在最小的源代码包压缩后大 18%。

只提供 .svn 目录，并让用户做 svn revert 的帮助不是很大（#2 vs #3），只能省掉 6% 的空间。