Fossil SCM

aka Fossil, a DVCS/Software Forge

http://fossil-scm.org/

FAQ http://fossil-scm.org/fossil/doc/trunk/www/qandc.wiki

manual http://www.fossil-scm.org/schimpf-book/index

written by Richard Hipp, creator of SQLite

Concepts (including Data Synch) http://fossil-scm.org/fossil/doc/trunk/www/concepts.wiki

architecture

• uses SQLite as its Data Store, is written in C
• http://fossil-scm.org/fossil/doc/trunk/www/theory1.wiki
  • Fossil is not based on a distributed No[[SQL]] database because Fossil is a distributed No[[SQL]] database. Fossil is not based on SQLite. The current implementation of Fossil uses SQLite as a local store for the content of the distributed database and as a cache for meta-information about the distributed database that is precomputed for quick and easy presentation. But the use of SQLite in this role is an implementation detail and is not fundamental to the design. Some future version of Fossil might do away with SQLite and substitute a pile-of-files or a key/value database in place of SQLite. (Actually, that is very unlikely to happen since SQLite works amazingly well in its current role, but the point is that omitting SQLite from Fossil is a theoretical possibility.)
  • Much of the "heavy lifting" within the Fossil implementation is carried out using SQL statements. It is true that these SQL statements are glued together with C code, but it turns out that C works surprisingly well in that role.

TeamWiki http://fossil-scm.org/fossil/doc/trunk/www/wikitheory.wiki If two users make unrelated changes to the same wiki page on separate repositories and those repositories are synced, the wiki page will fork. The web interface will display whichever edit was checked in last. The other edit can be found in the history. The file format will support merging the branches back together, but there is no mechanism in the user interface (yet) to perform the merge.

http://blog.mired.org/2011/02/fossil-sweet-spot-in-vcs-space.html