Hacker News Reader

Comment by erlanger | Hacker News Reader

Very robust (SQLite, and it expects HTTP for transmission). Fairly performant, though not quite as fast as Git. I agree with the creator's take on this,

Fossil takes the philosophy of the tortoise: reliability is more important than raw speed. The developers of fossil see no merit in getting the wrong answer quickly.

http://www.fossil-scm.org/index.html/doc/tip/www/selfcheck.w...

The website also makes the bold claim on the homepage that

In over two years of operation, no work has ever been lost after having been committed to a Fossil repository.

View on HN

Fossil takes the philosophy of the tortoise: reliability is more important than raw speed. The developers of fossil see no merit in getting the wrong answer quickly.

Considering that Git and Hg are as reliable as Fossil (AFAIK) but faster, this sounds like an excuse.

This fellow's not known for being full of crap, so I give him the benefit of the doubt. Take ten minutes, give it a try, then see what you think.

Oh, I believe all his claims about Fossil. My point is that it sounds like he's setting low goals.

I dunno what you consider reliable, but I don't trust git in the slightest. 3rd link down on a quick google search shows an august 2009 date (1st 2 links are both from 2006 on the git mailing list):

http://pastebin.ca/1549372

I've had git fuck with my code/data one too many times to fully trust it.

Could you flesh that out a little? Were they merges, broken commits, what? I haven't had problems with git, though perforce has gotten ugly for me on several times.

That stinks. On one hand, the beauty of DVCS is that you can clone from another repos that isn't corrupt, but this would still be a big problem in a bare (central) repository during a merge or if you were working offline for an extended period of time (in which case you just lose your diffs). Of course we all keep local projects with just one copy of the repository.

One great thing about Fossil is how easy it is to back up since it's a single file. I've always felt that million-file approach was clumsy, even when centralized in a single directory.

Monotone (http://www.monotone.ca/ : a DVCS that predates git by several years, and was a major inspiration) keeps its repositories in SQLite databases, as well. I used it for a while, kept my home directory in mtn, etc. SQLite databases are indeed quite easy to back up. (You're better off putting "echo .dump | sqlite3 dbfile.sql > dbfile.sql.bak" in cron, though - the dump is more portable.)

Using SQLite dbs for serialization is a great idea, particularly for prototyping. It's not quite as efficient as bespoke file formats and data structures, but frequently good enough, and getting transactions for free is a huge bonus.

Looks like git-svn corruption, not git corruption.

Reply on news.ycombinator.com