<title>Reviews</title>
<b>External links:</b>
* [http://nixtu.blogspot.com/2010/03/fossil-dvcs-on-go-first-impressions.html |
Fossil DVCS on the Go - First Impressions]
* [http://blog.mired.org/2011/02/fossil-sweet-spot-in-vcs-space.html |
Fossil - a sweet spot in the VCS space] by Mike Meyer.
* [http://blog.s11n.net/?p=72|Four reasons to take a closer look at the Fossil SCM] by Stephan Beal
<b>See Also:</b>
* [./quotes.wiki | Short Quotes on Fossil, Git, And DVCSes]
<b>Daniel writes on 2009-01-06:</b>
<blockquote>
The reasons I use fossil are that it's the only version control I
have found that I can get working through the VERY annoying MS
firewalls at work.. (albeit through an ntlm proxy) and I just love
single .exe applications!
</blockquote>
<b>Joshua Paine on 2010-10-22:</b>
<blockquote>
With one of my several hats on, I'm in a small team using git. Another
team member just checked some stuff into trunk that should have been on
a branch. Nothing else had happened since, so in fossil I would have
just edited that commit and put it on a new branch. In git that can't
actually be done without danger once other people have pulled, so I had
to create a new commit rolling back the changes, then branch and cherry
pick the earlier changes, then figure out how to make my new branch
shared instead of private. Just want to say thanks for fossil making my
life easier on most of my projects, and being able to move commits to
another branch after the fact and shared-by-default branches are good
features. Also not having a misanthropic command line interface.
</blockquote>
<b>Stephan Beal writes on 2009-01-11:</b>
<blockquote>
Sometime in late 2007 I came across a link to fossil on
<a href="http://www.sqlite.org/">sqlite.org</a>. It
was a good thing I bookmarked it, because I was never able to find the
link again (it might have been in a bug report or something). The
reasons I first took a close look at it were (A) it stemmed from the
sqlite project, which I've held in high regards for years (e.g. I
wrote JavaScript bindings for it:
<a href="http://spiderape.sourceforge.net/plugins/sqlite/">
http://spiderape.sourceforge.net/plugins/sqlite/</a>), and (B) it could
run as a CGI. That second point might seem a bit archaic, but in
practice CGI is the only way most hosted sites can set up a shared
source repository with multiple user IDs. (i'm not about to give out
my only account password or SSH key for my hosted sites, no matter how
much I trust the other developers, and none of my hosters allow me to
run standalone servers or add Apache modules.)
So I tried it out. The thing which bugged me most about it was having
to type "commit" or "com" instead of "ci" for checking in (as is
custom in all other systems I've used), despite the fact that fossil
uses "ci" as a filter in things like the timeline view. Looking back
now, I have used fossil for about about 95% of my work in the past
year (http://blog.s11n.net/?p=71), in over 15 source trees, and I now
get tripped up when I have to use svn or cvs.
So, having got over typing "fossil com -m ...", here's why I love it so much...
Point #1: CGI
Again, this sounds archaic, but fossil has allowed me to share source
trees which I cannot justifiably host in other projects I work on
(they don't belong to those projects), which I cannot host in google
code (because google code doesn't allow/recognize Public Domain as a
license, and I refuse to relicense just to accommodate them), and for
which SourceForge is overkill (and way too slow). With fossil I can
create a new repo, have it installed on my hoster
(http://fossil.wanderinghorse.net), and be commiting code to it within
5 minutes.
Point #2: Wiki
I hate wikis. I really do. Always have. They all have a different
syntax and the content tends to get really disorganized really
quickly. Their nature makes it difficult to reorganize them without
replacing old pages with lots of "has been moved to
<nowiki>[TheNewPage]</nowiki>"
links. I'm one of those "code for tomorrow" coders (i.e., code such
that it'll be easy to reorganize/refactor later). I like to document
the same way, and wikis make that problematic. Then again, no
documentation system is really good in that regard.
That said, fossil has made me love having a centralized, common
documentation platform. Whereas I used to document everything in the
API docs (header files) and often include an ODT file for a library
manual, fossil has become my preferred platform for non-API
documentation because it's just so easy to do. No matter where I am, I
can log in and write (I write a lot). The added ability to export my
wiki pages, edit them in xemacs, and re-import them just makes it
nicer, as I can tweak as much as I want without ending up with 10
"updated wiki page SoAndSo" messages in the commit log.
Point #3: running a server locally
Fossil runs not only as a CGI, but as a server. I don't WANT to host
my own server (and don't have the rights to on my hosters). I hate
server-side maintenance (a hate born from years of administering
systems). But the server has other uses. When working on the wiki, bug
reports, etc., the local server is *the* way to do it. It's blazingly
fast and much more productive. When you're done, just run "fossil
push" and everything's synced.
Point #4: the single-file repository
Having all controlled content inside a single container file has been
a godsend when it comes to backups and copying/moving a repository.
There are no access or file ownership issues, which are often
problematic with other server-side systems (at least on the initial
install). For about 5 years I administered a CVS repo for a company
for, and every time someone added a directory to the (huge and
dynamic) source tree I had to log in and "chmod 4775" the directory
before others could commit to it. Fossil's model inherently eliminates
that type of problem, and I'm a *huge* fan of solutions which
inherently (that is, due to their very nature) avoid certain
foreseeable problems. The single-file repository model's flexibility
would seem to become more problematic for huge repos (a few hundred
MB+) with many users with differing levels of access (e.g. OpenOffice,
Firefox, or the Linux Kernel), but 99.9% of projects never reach
anywhere near that size or complexity.
In summary:
I remember my first reaction to fossil being, "this will be an
excellent solution for small projects (like the dozens we've all got
sitting on our hard drives but which don't justify the hassle of
version control)." A year of daily use in over 15 source trees has
confirmed that, and I continue to heartily recommend fossil to other
developers I know who also have their own collection of "unhosted" pet
projects.
</blockquote>