
Fossil SCM (from SQLite's creator) - erlanger
http://www.fossil-scm.org/
======
gcv
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
_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
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.

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

~~~
gecko
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.

~~~
silentbicycle
> 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.

------
zach
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...](http://www.mail-archive.com/fossil-users@lists.fossil-
scm.org/msg00344.html)

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

~~~
erlanger
When do you have files that large in a project?

~~~
cschneid
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.

~~~
erlanger
I suppose, I never really version control those, just track the revisions by
uploading updates of the comps for the client, or using share drives if I'm
working with other designers. I don't think you can merge PSDs, so many of the
benefits of an SCM vanish.

~~~
cschneid
I agree, you lose the merging when you work with binaries (for the most part).

But when I was at HP, our little team was behind the curve in tool use, and I
was pushing for a comprehensive scm, instead of the patchwork we had. My big
selling point was that given a stack of windows and database install disks,
and the scm, you should be able to bootstrap the project up, and get it
running.

I really like that point of view when it comes to SCMs. It's the official
repository of everything project related. You have code, docs, graphics,
everything needed. You do lose out on merging and stuff with binaries, but
that's a small price to pay for the peace of mind you get.

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

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

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

~~~
riobard
Any idea about performance, robustness, etc?

~~~
erlanger
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...](http://www.fossil-
scm.org/index.html/doc/tip/www/selfcheck.wiki)

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

~~~
wmf
_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.

~~~
zenspider
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.

~~~
erlanger
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.

~~~
silentbicycle
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.

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

