On Mar 4, 2010, at 4:22 PM, [email protected] wrote: > Brian Smith writes: >> Hi All, >> >> I've been playing with fossil for a few weeks now and I've come to >> quite like it. >> I was a tad disappointed that a git import tool hadn't been written >> so, I went ahead and did that. >> You can find the tool at: https://code.linuxfood.net/pub/repo/git-import/home >> (please accept the self-signed certificate.) >
Interesting analysis. Thanks for providing it. Have you seen the similar study I did at: http://www.fossil-scm.org/fossil/doc/tip/www/stats.wiki I would be curious to know how much network traffic was needed to clone the Fossil repository in comparison to Hg and Git. You are correct that Fossil keeps a fair amount of redundancy in its local repository - under the theory that local mass storage is too cheap to meter. Network traffic, on contrast, costs more and tends to limit performance, so I was pleased to see that Fossil uses considerably less than 35MB of traffic to clone a 35MB repository, for example. The ratios are such that Fossil looks like it might clone your repository with an amount of traffic similar to the Git repository size. Fossil repositories do not normally need to be "vacuumed". The exception is when they have been newly constructed such as by clone - which vacuums automatically, or by the Git import tool. (Does that Git import tool vacuum the repository when it is done? I'm guessing not.) It is also sometimes necessary to vacuum after you upgrade the "fossil" executable. But for day-to-day operation Fossil maintains its compact size - similar to Hg, it seems. > > Hello, > > I must say that I was delighted from this news, because it > allowed me to test fossil on my current project, which is now hosted > in bitbucket to test fossil repository size performance on a > "real-world" project, medium sized, but not "toy". > > Unfortunately it is a closed-source project, but I can give some > statistics: it is written in Java, it has 4568 changesets and the > repository size is > > du .hg -> 16188 .hg > > First of all I have migrated this project in git using > fast-import. And I have this size > > du .git -> 29692 .git > > This before any repacking. After issuing > > git gc --aggressive > > I have this size: > > du .git -> 7172 .git > > So, we have shrunk the size from ~29 Megabyte to ~7, a very good > improvement, less then half then Mercurial size. > > ************** > > Then I use your tool to convert from git to fossil. > > First of all the uncompressed artifacts is: > > "du artifacts" -> 421304 artifacts/ > > Then I import the artifacts to reconstruct a fossil database > > (wait... wait...) > > the database size is 108 Megabyte. > > The admin page of fossil says to me: > > > Repository Size: 112292864 bytes > Number Of Artifacts: 14122 (stored as 2430 full text and 11692 delta > blobs) > Uncompressed Artifact Size: 27536 bytes average, 388868844 bytes total > Compression Ratio: 34:10 > Number Of Check-ins: 4067 > Number Of Files: 1288 > Number Of Wiki Pages: 0 > Number Of Tickets: 0 > Duration Of Project: 409 days > Project ID: 9b842a4a934a262146ae9596eaf754f94ab23ad3 > Server ID: 9e928a3b94474d11d4d7f791fa699646cda11482 > > > But this is not "optimal", because I have to VACUUM the database. > > I do it... and the size is now. > > 28136448 > > ~ 27 Megabyte. > > Curious enough... I try to compress the database file, just to know > how much "entropy" I can squeeze further. > > I use the 7z algorithm to compress the "VACUUMED" database file... and > the file size is: > > ~ 17 Megabyte > > So, in the end, a compressed database is similar in size to a > mercurial repository. > > > Another test... I "dump" the fossil database to a file. > > The text dump of the database is > > ~45 Megabyte > > Compressed with 7z algorithm it becomes: > > ~17 Megabytes > > More or less the same as the fossil db compressed. > > ===================== > > Conclusions. > ------------ > > > The "size winner" is git, but only with the "gc --aggressive" command, > which is a kind of "super-packing", but of course, continuing to make > commits on top of that will surely degrade this performance, because > the new objects will not be stored so compressed. > > Mercurial does a good job maintaining its repository size to around 17 > Megabyte; this is fairly good and it is without maintaneance. No > garbage collector or vacuum to perform. > > Fossil without "vacuum" is not so good. After a vacuum it has the same > size as git before the "gc" command. In any case it is higher than > mercurial. But, as the "7z" compression command showed, there is some > redundance left in a fossil database, probably due to the sqlite > storage mechanism. Probably, but I am not expert, this redundancy is > what makes fossil more "robust" in response to hardware or software > failures. > > > Lino > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users D. Richard Hipp [email protected] _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
