Fossil SCM (from SQLite's creator)

http://www.fossil-scm.org/

by erlanger • 17 years ago

96 29 17 years ago

fossil-scm.org

erlanger6• 17 years ago

Description, and what led me to submit this: http://news.ycombinator.com/item?id=809480

riobard• 17 years ago

Any idea about performance, robustness, etc?

erlanger6• 17 years ago

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.

silentbicycle4• 17 years ago

Looks interesting. A lightweight (fully self-contained in one <2mb file) distributed version control system, with built-in wiki and bugtracker, written by the author of SQLite. Since it stores everything in SQLite, the entire repo can be copied around as one file, and solid transactions are already implemented. (It's probably quite portable.) It doesn't look like it has a library/API to use it as a storage backend, yet. Oh, and it's released under the GPL v. 2.

Word of warning: fossil open (checking out a project from the repo file) tarbombs the project into the current directory by default.

At a quick glance: it looks easy to use, the bug tracker and wiki look decent. It seems to be focused heavily on reliability (never corrupting the repo), at the possible expense of speed. It seemed slower than git, but likely still faster for day-to-day usage than non-distributed VCs. I don't have any pressing reason to switch from git, but I'm curious if anybody else here has comments from more than a few hours experience with it.

gecko2• 17 years ago

Sure, I've got a bunch, since I rather infamously screwed around with it after Eric Sink said it was the DVCS he was most interested in. In particular order:

Fossil wants to GPG-sign everything by default, and doesn't get along well with gnupg2. That means no gpg-agent, which means typing your password every time you make a commit.

Until recently, Fossil lacked private branches. Fossil now has private branches, with a twist: merging a private branch into a named branch shows up as a single commit, much as if you had qfold/git rebase -i'd them in Mercurial or Git. Multiple private branch support is still clumsy. Selectively pushing branches, as in Mercurial, is impossible.

Merging support is still very young. Fossil does not handle renaming a file in one branch and making changes in another at all; you'll lose either the changes, the rename, or both. Thankfully, the autosync feature, enabled by default, encourages you to stay rigorously up-to-date, lessening the chance of this occurring.

The SQLite schema still changes fairly often, so you'll need to "fossil rebuild all" fairly often, if you're keeping up-to-date.

Fossil is quite dependent on the integrated web server for using the tool. While most of the functionality is available from the command line, some isn't, and that which is, is frequently undocumented. The web interface, thankfully, is quite easy to use.

Fossil lacks any real patch management, which will be a disappointment for projects used to sending patches by email. It also lacks any support for git-diffs or similar, meaning that some changes stored by Fossil cannot be properly represented to the user.

I find Fossil's separation of repository from working directory highly annoying. Other users love it, and others don't care. Your mileage may vary.

I'm continuing to keep an eye on Fossil, if only because, with Mercurial and Git increasingly well-established, it's the only DVCS that brings anything remotely new to the table. That said, it's got a ways to go before I think it'll be of interest to most projects.

silentbicycle4• 17 years ago

> That means no gpg-agent, which means typing your password every time you make a commit.

Yikes. Monotone also made you do crypto auth setup upfront, which meant that starting up a new repository had a couple key/user-related steps that made it seem cumbersome compared to git or hg.

wanderingmarker• 17 years ago

Thanks for posting this. Fossil has many good ideas. Since I rather like learning about source control systems, I took this one for a spin.

It's definitely pretty fast, although I didn't stress-test it. It noticed that I have GPG set up, and prompted me to sign all my commits by default. Very nice. It has no Git-style index, but commits straight to the repository like Mercurial. I did not find anything like "git add --patch" or darcs partial commits, so saving work seem to be all-or-nothing. Like any good modern VCS, Fossil seems to do real branching and merging, although I did not stress-test that, either.

One major downside: if Fossil has file move detection, I didn't find it. So you have to either spend some time informing it that you moved or renamed things (luckily, you can do this after the fact), or you need to use Fossil-aware tools.

there• 17 years ago

One major downside: if Fossil has file move detection, I didn't find it.

i couldn't find it on the website, so i downloaded it and it does appear to support renaming files.

   jcs@smug:~/Downloads% ./fossil help mv
   Usage: ./fossil mv|rename OLDNAME NEWNAME
      or: ./fossil mv|rename OLDNAME... DIR

   Move or rename one or more files within the tree

gcv• 17 years ago

Yes, that's an explicit move. That's what I mean by informing the VCS that you renamed a file. It amounts to holding the VCS's hand and means that even trivial code rearrangements require considerable extra care, or explicit support for that precise VCS type from the IDE. Git and Mercurial autodetect moves, so you can freely use any regular tools you want to manipulate your files (command shell, Windows Explorer, Finder, IDE), and "git add -A" or "hg addremove" will properly record your changes.

zach• 17 years ago

For those interested, I found an answer to one of the less-frequently asked questions in a recent mailing list message.

Q. How large of an individual file is Fossil designed to comfortably work with?

A. Under 10 MB.

http://www.mail-archive.com/fossil-users@lists.fossil-scm.or...

So, as you would expect for an SQLite-backed system, it's only useful for source-code-sized files. Look elsewhere for archiving and versioning your data sources unless they're tiny (< 0.007% of a MacBook hard drive).

erlanger6• 17 years ago

When do you have files that large in a project?

cschneid2• 17 years ago

Photoshop mockup of a page?

On one hand "don't store binaries" on the other, it's a work product for the project, and it makes sense to be stored and versioned.

holygoat• 17 years ago

Here are three:

* Sample data for test suites. I have single files of such larger than 21MB in my current project's git repo, and I've seen much bigger. * Audio resources. * Large PDF documentation items.

modoc• 17 years ago

Large SQL scripts, large images/video (I have one web app where the project is 1.3 GB), PSDs, PDFs, web apps that allow you download binaries (installers, software, etc...).

All in all, I'd say that 70% of projects I've worked on have had files in SVN that are bigger than 10 MB.

oomkiller• 17 years ago

There are some nice ideas here, but it's too different from what I'm used to for me to use it full time (I use Git). I am interested if there is a way to get bug tracking and a wiki and store it in a git repo somewhere in the .git directory. Might be a nice feature for git 2.0 :)

zokier• 17 years ago

Interesting. I wonder if it could be ported to a "real" SQL-server like PostgreSQL, for greater performance in multi-user environment (ie. central server).

gecko2• 17 years ago

At the moment, no. The DB access is hard-coded to use SQLite, and some SQLite-specific features are used.

c00p3r• 17 years ago

One binary might be a good idea, but it seems like trac.edgewall.org is superior. Design and big community matters.

Fossil SCM (from SQLite's creator)

Related Stories