As much as I like the simplicity of keeping the full repository history in one single SQLite database, I see a minor downside.
There's a lot of backup traffic, if "non-contents changes" (such as the admin and user logs, the login cookies, but also the "PRAGMA optimize" information) are causing updates to the repository database, marking it dirty for the next backup cycle. (This was also the main reason for my complaining about the leftover WAL and SHM files, recently, which accumulated in my backup logs. Because in the end, WAL and SHM have to be kept together with the SQLite database, as they might contain valuable information?) From peeking at the Fossil timeline, my question is, will the new "backoffice processing" cause even more frequent updates to the main repository database, i.e. with the pids stored in the configuration table, and updated after each web page display? I have created a (surprisingly simple) patch to attach a separate login cookie database (shared among all repositories in the same directory), so that plain login and logout actions will no longer cause repository database writes. With admin and user logs turned off, and "PRAGMA optimize" removed, the repository database is only touched if there's new contents, or new configuration settings. What's your comments to this? Does anybody care about the repository database, holding all your valuable contents, being modified frequently with simple non-contents state information? Given the reliability of SQLite, we probably shouldn't care. But what is a good strategy to minimize backup traffic, if repository databases change that often? --Florian _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
