Hacker News Reader

Comment by avgjo | Hacker News Reader

I've used Fossil for a private local project. It's quite a capable revision control system with a very decent web UI. Just a word of warning - make frequent backups of the backing sqlite repository database. I had upgraded fossil to make a few commits and then I inadvertently made a commit using an older version of fossil and it corrupted the fossil repo database irreparably and a few days' of work was lost. I've never had GIT corrupt a repo in ten years of daily use - regardless of version.

View on HN

As a counterpoint, I've been completely unreasonable with my use of fossil. Wildly different versions on different systems, often from years apart. They get whatever binary existed when I set up the system and stay on it. Some osx, some variations of Linux, a freebsd box. I think windows if I go back far enough. Synchronising between them in ad hoc fashion.

Some repos are over a decade old. One is over 10k commits deep, another several gigabytes in size because I checked in whole dev environments.

Every now and again it told me it wanted to rebuild and that succeeded. I routinely ctrl-c it partway through a commit if I notice a typo.

It has _never_ dropped the ball on me. Fossil is by a wide margin the most reliable program I've ever used.

I dispute this claim. The underlying artifact format for Fossil is compatible back to the beginning. There have been enhancements, but nothing that would break. And there have been no reports of breakage among the countless users on the Fossil Forum.

I suspect what the OP encountered was that he checked in some things using a newer version of Fossil that had enhanced capabilities. (For example, Fossil originally only use SHA1 hashes, but was enhanced to support both SHA1 or SHA3 after the SHAttered attack.) Then the OP tried to extract using an older Fossil that didn't understand the new feature and returned an error. I'm guessing at this, of course, but that seems like the most likely scenario.

I have never once made a backup of SQLite repo or the Fossil self-hosting repo, or any of the other 100+ Fossil repositories that I have at hand. I've cloned the repos to other machines as disaster protection. In fact, I have cron jobs running on machines all over the world that "sync" critical Fossil repositories (such as SQLite) once an hour or so. But I have never even once made a pure backup.

I did have the primary SQLite repo go corrupt on my once, years ago. Somehow, file descriptor 2 got closed. Then when the SQLite database that is the repository was opened, it opened on file descriptor 2. Then some bug in Fossil caused an assert() to fire which wrote on file descriptor 2, overwriting part of the database. I restored the repo from a clone, fixed the assertion fault in Fossil, and enhanced SQLite so that it refuses to use a file descriptor less than 3.

Is it a known behavior? Considering SQLite developers approach to reliability, I think it would count as a critical bug worth fixing.

Afaik fossil just uses sqlite under the hood to store metadata. It would surprise me sqlite doesnt stash min and max required versions and refuse to work outside of those bounds

It does do exactly that. If you visit https://sqlite.org/src/stat, the "Schema Version" line tells you exactly what version of the database schema that the repository is using. The SQLite repository uses the very latest Fossil schema, which you can see from the "stat" page has not changed in 8.5 years.

Thanks for comment. Yeah I figured parent comment was suspect

It is yes, they've even built a command for it "rebuild"[0]

> Reconstruct the named repository database from the core records. Run this command after updating the fossil executable in a way that changes the database schema.

[0]: https://fossil-scm.org/home/help?cmd=rebuild

I have had git corrupt repos. But usually not irreparably.

Reply on news.ycombinator.com