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.)
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
