On 10/18/16, Scott Doctor <sc...@scottdoctor.com> wrote: > > Assume many check-ins occurred with many changes over many > files. Seems that if something glitches everything can become > out of sync and hard to recover. My question, is there is a way > to tell fossil to store the complete versions of the documents > instead of it recreating the documents by piecing all those > fragments together. My concern is that something goes wrong, > perhaps a bad disk sector not necessarily a software issue, that > would further complicate recover. >
Content is checked to make sure it is recoverable prior to running the COMMIT that stores it in the database. If any content is not recoverable, Fossil runs a ROLLBACK instead. See https://www.fossil-scm.org/fossil/doc/trunk/www/selfcheck.wiki for further information. To guard against hardware bugs damaging the database, clone the database on multiple machines and keep them in sync automatically. You are more likely to have a complete disk failure or some other local disaster (a fire or flood) and loss everything than a single bad sector. Turning off the delta compression will not save you from a flood or fire. So if you have important content, be sure to clone the repo to multiple geographic locations. The Fossil self-hosting repositories are stored on leased servers located in three different data centers, each at least 500 miles distant from the others. Server space is leased from two different companies to prevent a common-mode failure at a single ISP. All content is kept in sync using cron jobs that runs "fossil sync -u" very hour or so. And, of course, there are countless private clones of Fossil that can also be used for recovery. There was once a double-bug in Fossil and stunnel that corrupted the canonical Fossil repository database, breaking the delta chain, and making downstream content unrecoverable. The first problem was that stunnel was launching Fossil without opening file descriptor 2 (stderr). The database was opened on the first available file descriptor, which was 2. Then a bug in Fossil caused an assert() to fire which did write(2,...) to put an error message smack in the middle of the database file. All content was recovered using one a clone. SQLite was subsequently enhanced to never open a database using a file descriptor less than 3 so this error can never happen again. But who knows what other subtle problems lurk undetected. Also clone data you care about. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
