I’m in the process of taking a hard look at Fossil for source control. I’d heard of it a long time ago, but only briefly considered it before getting swept up in the rise of Mercurial and git. The only thing that put it back on the radar was a brief mention in some Hacker News discussion, and a recent FLOSS Weekly episode.
I used git daily at work and at home, and I know it well. I like it too, and it’s incredibly powerful. The world has Github, which is both convenient super-productive, so why spend time looking at Fossil? If it was just another DVCS with a different different syntax, I’d probably not stay long. But it’s more that that, and the differences from git are intriguing, so I’m trying it out in my workflow.
Some initial impressions (since this is the only time I’ll have them), in no particular order:
- Installation is simple on all platforms I’ve tried (OSX, Win7, Linux). While I understand that
brew/aptitude install blahis easy too, it isn’t simple when that installation results in dozens of packages/files/folders being installed. Fossil is a small, standalone binary. - Making new repos is easy just like git, but I like Fossil’s all-in-one-file approach better than the git’s pile of files under
/.git. - I like being able to check out of branch from the repo and just getting those files in whatever folder I’m in, and opposed to cloning the repo.
- The basic CLI is fine, though I’m so used to git it will take time to really judge this one fairly. The breadth of commands and options in git dwarfs Fossil.
- The built-in server is great, and is the main thing that piqued my interest. The web UI gives a good overview of repo action, but also provides an integrated wiki and ticket system. All of this is versioned and part of the same repo file. At first blush it sounds like just bolting on features (there are dozens of wikis and tickets systems out there…), but IMHO it’s really nice to get these basics for free, attached right to the project. Don’t use them if you don’t want to, but they’re there if needed. (Oh, and that server process running on Windows: 1.5 MB of memory usage…)
- Sync between repos has worked flawlessly. The model, for better and worse, is basically that everything is connected and global. There aren’t a bunch of local branches and forks and splinter repos. I was able to set up Fossil on my VPS in less than 10 minutes as a more central sync point, but syncing between any two repos works equally well.
- There are no submodules, which I’m not crying over.
- I miss rebase. (Warning: start of rant) There are some fairly dug-in anti-rebase philosophies held by the Fossil principals that seem more stubborn & contrarian than useful. Their notion that rebase is antithetical to an SCM’s core role indicates a lack of understanding of rebase. Let’s just take the “preserve all history” ideal to an absurd extreme and say it’s unacceptable that one can simply use their backspace key with no record of it. That’s my reaction when I read the old anti-rebase posts on the Fossil mailing list. rebase is used to clean things up before publication. Just like I’ll edit files before committing them, so I’ll edit/rearrange commits before publishing them. That’s it. Anyone whose had to collaborate on a Word document, let me ask you this: how pleasant is it to have all edits by everyone visible? You’d probably just like to read the document, at least in most cases. Well without easy squash and rebase, it seems harder to get branches in a good state with Fossil. Deal breaker? No. But definitely a bit frustrating.
- I miss the git staging area and staging/reverting parts of edits. I do agree the staging area can be confusing to newcomers, but it quickly becomes a useful step in the workflow. There is probably just a different working in Fossil that I need to learn.
- The Fossil documentation is a bit of a mixed bag, but is pretty good overall. The system isn’t nearly as complicated as git and really doesn’t need a lot of documentation.
- The community is inviting, and responsive. I submitted a ticket for a very minor issue and it was fixed (on a development branch) in less than four hours.
- The whole thing is just a bit quirky, in a good way. The main author, D. Richard Hipp (of SQLite fame), basically says that he wrote Fossil to manage SQLite and if others like it, fine. But then there are pockets of diehard Fossil zealots from disparate backgrounds. The whole thing is less serious, less complicated, and more fun than git.
Next time I’ll get into how I’m actually using Fossil for side projects differently than what I could do with git.