1 files changed, 138 insertions, 0 deletions
diff --git a/www/reviews.wiki b/www/reviews.wiki
new file mode 100644
index 0000000..db06398
--- /dev/null
+++ b/www/reviews.wiki
@@ -0,0 +1,138 @@
+<title>Reviews</title>
+<b>External links:</b>
+
+  *  [https://www.nixtu.info/2010/03/fossil-dvcs-on-go-first-impressions.html |
+     Fossil DVCS on the Go - First Impressions]
+
+<b>See Also:</b>
+
+  *  [./quotes.wiki | Short Quotes on Fossil, Git, And DVCSes]
+
+<b>Daniel writes on 2009-01-06:</b>
+
+<div class="indent">
+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!
+</div>
+
+
+<b>Joshua Paine on 2010-10-22:</b>
+
+<div class="indent">
+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.
+</div>
+
+<b>Stephan Beal writes on 2009-01-11:</b>
+
+<div class="indent">
+Sometime in late 2007 I came across a link to fossil on <a
+href="https://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 bindings for
+it for Mozilla's SpiderMonkey JavaScript engine), 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, 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
+(https://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.
+</div>