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