当我测量服务器上的文件夹大小时,我有一个8 GB的SVN存储库。
但是当我在本地检查出来时(只是从根目录检查完整的存储库,所有分支/标签)它的50+ GB(仍在计数)。
SVN似乎在压缩其内容方面做得很好。为什么尺寸如此不同?
有没有办法计算存储库的实际大小而无需在本地进行全面检查?
答案 0 :(得分:5)
在存储库中创建文件夹的分支时,实际上不会复制该文件夹的内容。仅仅在重复数据上浪费空间毫无意义。有关详细信息,请参阅好书中有关分支的章节,尤其是标题为Cheap Copies
的{{3}}部分末尾的带框文字。
至于实际大小的问题,没有办法计算我所知道的,但我怀疑是否有必要。如果没有房间,那就腾出一些空间。重点是您不需要工作副本中的所有分支,因此仅结帐Creating Branches。
答案 1 :(得分:2)
你可以尝试来修改修订版本的大小,而不用checkout(需要一些技巧和手工)来完整树的repo中的任何子树(完整的树是,无论如何,坏主意和浪费的空间)
svn ls -v -R ROOT/OF/ > file.log
1300lazybadgмай072014 city /
(斜线在字符串的最后位置,字符串包含一个字段,比文件相关的字符串小)
awk
表示)的所有值(以字节为单位)求和625 Infinity 1272 янв 22 2010 city/Siberia.bmp
来自我的小型仓库的样品
全ls
5 lazybadg фев 07 2014 ./
2 lazybadg ноя 28 2013 branches/
2 lazybadg ноя 28 2013 branches/FullHTML/
2 lazybadg 1521542 ноя 28 2013 branches/FullHTML/natasha_i_budushee.html
2 lazybadg 146 ноя 28 2013 readme.textile
1 www-data ноя 27 2013 tags/
5 lazybadg фев 07 2014 trunk/
5 lazybadg 46394 фев 07 2014 trunk/G1.txt
2 lazybadg 22203 ноя 28 2013 trunk/G10.txt
2 lazybadg 18974 ноя 28 2013 trunk/G11.txt
2 lazybadg 23795 ноя 28 2013 trunk/G12.txt
2 lazybadg 24996 ноя 28 2013 trunk/G13.txt
2 lazybadg 27358 ноя 28 2013 trunk/G14.txt
2 lazybadg 24855 ноя 28 2013 trunk/G15.txt
2 lazybadg 22481 ноя 28 2013 trunk/G16.txt
2 lazybadg 40970 ноя 28 2013 trunk/G17.txt
2 lazybadg 27761 ноя 28 2013 trunk/G18.txt
2 lazybadg 33974 ноя 28 2013 trunk/G19.txt
2 lazybadg 38287 ноя 28 2013 trunk/G2.txt
2 lazybadg 30880 ноя 28 2013 trunk/G20.txt
2 lazybadg 24692 ноя 28 2013 trunk/G3.txt
2 lazybadg 38140 ноя 28 2013 trunk/G30.txt
2 lazybadg 36509 ноя 28 2013 trunk/G31.txt
2 lazybadg 57408 ноя 28 2013 trunk/G32.txt
2 lazybadg 74241 ноя 28 2013 trunk/G34.txt
2 lazybadg 74800 ноя 28 2013 trunk/G36.txt
2 lazybadg 22123 ноя 28 2013 trunk/G4.txt
2 lazybadg 12631 ноя 28 2013 trunk/G5.txt
2 lazybadg 32373 ноя 28 2013 trunk/G6.txt
2 lazybadg 16433 ноя 28 2013 trunk/G7.txt
2 lazybadg 25243 ноя 28 2013 trunk/G8.txt
2 lazybadg 17669 ноя 28 2013 trunk/G9.txt
Dirs删除
2 lazybadg 1521542 ноя 28 2013 branches/FullHTML/natasha_i_budushee.html
2 lazybadg 146 ноя 28 2013 readme.textile
5 lazybadg 46394 фев 07 2014 trunk/G1.txt
2 lazybadg 22203 ноя 28 2013 trunk/G10.txt
2 lazybadg 18974 ноя 28 2013 trunk/G11.txt
2 lazybadg 23795 ноя 28 2013 trunk/G12.txt
2 lazybadg 24996 ноя 28 2013 trunk/G13.txt
2 lazybadg 27358 ноя 28 2013 trunk/G14.txt
2 lazybadg 24855 ноя 28 2013 trunk/G15.txt
2 lazybadg 22481 ноя 28 2013 trunk/G16.txt
2 lazybadg 40970 ноя 28 2013 trunk/G17.txt
2 lazybadg 27761 ноя 28 2013 trunk/G18.txt
2 lazybadg 33974 ноя 28 2013 trunk/G19.txt
...
由于显而易见性而未显示求和,但是
结帐的实际尺寸将大于计算尺寸,因为带有元数据的.svn
目录也需要WC中的一些空间
答案 2 :(得分:0)
我在测量文件夹大小时有一个8 GB的SVN存储库 服务器。
但是当我在当地检查出来时(只需检查完整的 存储库从根,所有分支/标签)其50+ GB(仍然 计数)。
不从存储库根目录检出工作副本,除非您需要在工作站上安装所有项目分支,标记和工具架。通常,您不需要这样的工作副本来进行SVN的日常工作。
SVN似乎在压缩其内容方面做得很好。怎么会 尺寸是如此不同?
分支,标记,货架(和复制操作)在服务器端的存储库存储系统中占用的空间不大。例如,存储库中的新分支应占用最少的空间(几千字节)。 SVN中的分支或标记是cheap copy。当您创建分支或标记时,Subversion实际上不会复制存储库中的任何数据。此外,SVN repos使用其他几种技术来节省空间。
但是,工作站上repo root的本地工作副本将按原样包含所有分支,并且将占用比存储库中更多的空间。
有没有办法计算存储库的实际大小 无需在当地进行全面检查?
整个Subversion存储库的磁盘使用量或大小
只需检查磁盘上存储库的大小。
如果您使用VisualSVN Server,请尝试Measure-SvnRepository cmdlet。它将产生以下输出:
Name Revisions Size SizeOnDisk
---- --------- ---- ----------
MyRepo 498 3,340 KB 4,529 KB
MyRepo2 479 21,313 KB 22,571 KB
MyRepo3 201 1,032 KB 2,226 KB
MyRepo5 2 71 KB 90 KB
您还可以使用 svnfsfs stats 工具查看和检查存储库存储统计信息。这是一个例子:
svnfsfs stats C:\Repositories\MyRepository